Suggestions for the dpdk stable tree

Suggestions for the dpdk stable tree

[Christian Ehrhardt]

Hi,
there is a stable tree for dpdk 2.2 at http://dpdk.org/browse/dpdk-stable/
But it is still at the 2.2 Release status.

I was working on testing 2.2 and needed to pull in some patches from post
2.2 release to fix issues.
After that I started to "scan" the git log what else might apply to a clean
and uncritical addition to a dpdp-2.2 as "stability backports".

I had a focus on identifying:
- only patches to components that are enabled in our packaging (well that
is close to the default conf so it should be ok for you as well)
- issues that have a real chance to occur
- patches that are small, so review is not overly complex
- apply without manual adaption (offset ok to some extend, no fuzz, no
manual fix)
I realized that I should suggest that list of patches to you to consider
adding it to the stable tree.
So therefore for you to consider:


commit d3a274ce9dee28118b8647e0db72ef0f4b6a6323

    app/testpmd: handle SIGINT and SIGTERM

commit 308df2bfba3d238fc1d2d16cc10c84681803b408

    Handle SIGINT and SIGTERM in l3fwd.

commit da82ee17e6ea99bf2931383ac33b0caccaaaefce

    tools: fix unbinding failure handling

commit 16c1814c802c205f6d3c32e3d3d10de9f87e7f22

    tools: support Python 3 in bind script

commit bb9f408550d13af6c1da104b0d9d9b9837f69bde

    tools: support binding to built-in kernel modules


commit 6e7caa1ad9d597fed0a49468af25ae6e68b8c443

    eal/linux: support built-in kernel modules


commit 86f36ff9578b5f3d697c8fcf6072dcb70e2b246f

    mempool: fix leak when creation fails


commit ca67ed289a76f38d6c4a4021985a36eaf1d77e28

    vhost: fix leak of fds and mmaps


commit fa11a8a7251e14eca0a4190128732386f13551bd

    port: fix crash for ring writer nodrop

commit 04f366906ab395c8047bebfc1ddea244dfcb40f5

    port: fix crash for ethdev writer nodrop


commit c7a4ff80722e9237a4c504106d21ba5ca27d8df2

    i40e: fix overflow

commit 097e920c32bf19cf918cc071525f33b0abdeebaf

    i40e: fix inverted check for no refcount

commit 330aa319382aec9ea595f9ebcb9a3c44647ad66c

    i40e: fix VLAN filtering

commit 9f44dd3d8ad447c7f797a9564d30a15e5ab7f72b

    i40e/base: fix missing check for stopped admin queue

commit 8a8807369ffafef90c410279b4b2645d2d7a7483

    i40e/base: fix driver load failure


commit 7656a546c0609f3205558a5d48352c82607d38d3

    fm10k: fix VLAN flag in scattered Rx


commit c6fb0e55585206a89f6db396de860e6e844cad06

    pcap: fix captured frame length


commit 6e02723754fb2b341701ac438486b2dfea98b523

    bonding: fix detach of bonded device

commit df3e8ad73f4c92b4eb8f49ff33271d4a09e6a04a

    bonding: fix detach of slave devices

commit 786c990a11e6e6592dfdee02840877070aa3a79a

    bonding: copy entire config structure in mode 4

commit 6698820b5f6d955b6af2b916e1074db236d4f5a2

    bonding: do not ignore multicast in mode 4

commit 8997a10bfcad789d000debaac4cd85cd3db57997

    bonding: fix active slaves with no primary

commit 7a7122edf1c8d63e516d1b2c2eff6fa9b54e0f82

    bonding: do not activate slave twice

commit 2186fff3675d4e774cecc8f918c05063e0367d28

    bonding: fix crash when no slave device


commit 3b1e3e4e362453df8cecbc6d481444be8b84326e

    virtio: fix descriptors pointing to the same buffer

commit c680a4a88c4312068f60937a7ba51eac8211c9a6

    virtio: fix crash in statistics functions

commit 9a0615af7746485d73d10561cc0743bc2fcd4bf7

    virtio: fix restart


Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: Suggestions for the dpdk stable tree

[Christian Ehrhardt]

Hi,
I guess over time/releases less people mind the 2.2-stable.
But I still see a lot of people referring to 2.2 - so why not giving this
thread a ping again.

ack / nack / opinions ?

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Thu, Mar 24, 2016 at 8:14 AM, Christian Ehrhardt <
christian.ehrhardt@canonical.com> wrote:

> Hi,
> there is a stable tree for dpdk 2.2 at http://dpdk.org/browse/dpdk-stable/
> But it is still at the 2.2 Release status.
>
> I was working on testing 2.2 and needed to pull in some patches from post
> 2.2 release to fix issues.
> After that I started to "scan" the git log what else might apply to a
> clean and uncritical addition to a dpdp-2.2 as "stability backports".
>
> I had a focus on identifying:
> - only patches to components that are enabled in our packaging (well that
> is close to the default conf so it should be ok for you as well)
> - issues that have a real chance to occur
> - patches that are small, so review is not overly complex
> - apply without manual adaption (offset ok to some extend, no fuzz, no
> manual fix)
> I realized that I should suggest that list of patches to you to consider
> adding it to the stable tree.
> So therefore for you to consider:
>
>
> commit d3a274ce9dee28118b8647e0db72ef0f4b6a6323
>
>     app/testpmd: handle SIGINT and SIGTERM
>
> commit 308df2bfba3d238fc1d2d16cc10c84681803b408
>
>     Handle SIGINT and SIGTERM in l3fwd.
>
> commit da82ee17e6ea99bf2931383ac33b0caccaaaefce
>
>     tools: fix unbinding failure handling
>
> commit 16c1814c802c205f6d3c32e3d3d10de9f87e7f22
>
>     tools: support Python 3 in bind script
>
> commit bb9f408550d13af6c1da104b0d9d9b9837f69bde
>
>     tools: support binding to built-in kernel modules
>
>
> commit 6e7caa1ad9d597fed0a49468af25ae6e68b8c443
>
>     eal/linux: support built-in kernel modules
>
>
> commit 86f36ff9578b5f3d697c8fcf6072dcb70e2b246f
>
>     mempool: fix leak when creation fails
>
>
> commit ca67ed289a76f38d6c4a4021985a36eaf1d77e28
>
>     vhost: fix leak of fds and mmaps
>
>
> commit fa11a8a7251e14eca0a4190128732386f13551bd
>
>     port: fix crash for ring writer nodrop
>
> commit 04f366906ab395c8047bebfc1ddea244dfcb40f5
>
>     port: fix crash for ethdev writer nodrop
>
>
> commit c7a4ff80722e9237a4c504106d21ba5ca27d8df2
>
>     i40e: fix overflow
>
> commit 097e920c32bf19cf918cc071525f33b0abdeebaf
>
>     i40e: fix inverted check for no refcount
>
> commit 330aa319382aec9ea595f9ebcb9a3c44647ad66c
>
>     i40e: fix VLAN filtering
>
> commit 9f44dd3d8ad447c7f797a9564d30a15e5ab7f72b
>
>     i40e/base: fix missing check for stopped admin queue
>
> commit 8a8807369ffafef90c410279b4b2645d2d7a7483
>
>     i40e/base: fix driver load failure
>
>
> commit 7656a546c0609f3205558a5d48352c82607d38d3
>
>     fm10k: fix VLAN flag in scattered Rx
>
>
> commit c6fb0e55585206a89f6db396de860e6e844cad06
>
>     pcap: fix captured frame length
>
>
> commit 6e02723754fb2b341701ac438486b2dfea98b523
>
>     bonding: fix detach of bonded device
>
> commit df3e8ad73f4c92b4eb8f49ff33271d4a09e6a04a
>
>     bonding: fix detach of slave devices
>
> commit 786c990a11e6e6592dfdee02840877070aa3a79a
>
>     bonding: copy entire config structure in mode 4
>
> commit 6698820b5f6d955b6af2b916e1074db236d4f5a2
>
>     bonding: do not ignore multicast in mode 4
>
> commit 8997a10bfcad789d000debaac4cd85cd3db57997
>
>     bonding: fix active slaves with no primary
>
> commit 7a7122edf1c8d63e516d1b2c2eff6fa9b54e0f82
>
>     bonding: do not activate slave twice
>
> commit 2186fff3675d4e774cecc8f918c05063e0367d28
>
>     bonding: fix crash when no slave device
>
>
> commit 3b1e3e4e362453df8cecbc6d481444be8b84326e
>
>     virtio: fix descriptors pointing to the same buffer
>
> commit c680a4a88c4312068f60937a7ba51eac8211c9a6
>
>     virtio: fix crash in statistics functions
>
> commit 9a0615af7746485d73d10561cc0743bc2fcd4bf7
>
>     virtio: fix restart
>
>
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
>

Re: Suggestions for the dpdk stable tree

[Mcnamara, John]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Christian Ehrhardt
> Sent: Friday, May 20, 2016 9:07 AM
> To: dev <dev@dpdk.org>; Stephen Hemminger <stephen@networkplumber.org>
> Subject: Re: [dpdk-dev] Suggestions for the dpdk stable tree
> 
> Hi,
> I guess over time/releases less people mind the 2.2-stable.
> But I still see a lot of people referring to 2.2 - so why not giving this
> thread a ping again.
> 
> ack / nack / opinions ?

Hi Christian,

We are interested in having a LTS/Stable tree.

We have been looking at identifying a maintainer and validation engineer internally to support the effort but haven't be able to finalize that. Once we do we will come back to the mailing list with a proposal and a request for comments.

We would probably be looking at 16.04 or even 16.07 as the basis for the LTS at this stage.

It would be great if we could get support from you or others as well.

John.
-- 

Re: Suggestions for the dpdk stable tree

[Christian Ehrhardt]

Hi,
it would be great to have an actively maintained LTS release.

Clearly all us "Distribution People" like Panu, Me and a few others should
- whenever bugs are identified as potential backports - start the
discussion.
And having an stable-maintainer on the other end sounds great.

The active maintainer you provide would do the usual auto-backport of fixes
once they come up upstream.
While us others would provide input from real exposure to users that flows
in via bug tracking tools.

Looking forward for you coming back to the list once you have found one.


Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Fri, May 20, 2016 at 4:49 PM, Mcnamara, John <john.mcnamara@intel.com>
wrote:

> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Christian Ehrhardt
> > Sent: Friday, May 20, 2016 9:07 AM
> > To: dev <dev@dpdk.org>; Stephen Hemminger <stephen@networkplumber.org>
> > Subject: Re: [dpdk-dev] Suggestions for the dpdk stable tree
> >
> > Hi,
> > I guess over time/releases less people mind the 2.2-stable.
> > But I still see a lot of people referring to 2.2 - so why not giving this
> > thread a ping again.
> >
> > ack / nack / opinions ?
>
> Hi Christian,
>
> We are interested in having a LTS/Stable tree.
>
> We have been looking at identifying a maintainer and validation engineer
> internally to support the effort but haven't be able to finalize that. Once
> we do we will come back to the mailing list with a proposal and a request
> for comments.
>
> We would probably be looking at 16.04 or even 16.07 as the basis for the
> LTS at this stage.
>
> It would be great if we could get support from you or others as well.
>
> John.
> --
>
>

Re: Suggestions for the dpdk stable tree

[Markos Chandras]

Hi,

On 05/20/2016 04:54 PM, Christian Ehrhardt wrote:
> Hi,
> it would be great to have an actively maintained LTS release.
> 
> Clearly all us "Distribution People" like Panu, Me and a few others should
> - whenever bugs are identified as potential backports - start the
> discussion.
> And having an stable-maintainer on the other end sounds great.
> 
> The active maintainer you provide would do the usual auto-backport of fixes
> once they come up upstream.
> While us others would provide input from real exposure to users that flows
> in via bug tracking tools.
> 
> Looking forward for you coming back to the list once you have found one.

Yes that sounds like a very good idea indeed!

-- 
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

Re: Suggestions for the dpdk stable tree

[Yuanhan Liu]

On Fri, May 20, 2016 at 02:49:31PM +0000, Mcnamara, John wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Christian Ehrhardt
> > Sent: Friday, May 20, 2016 9:07 AM
> > To: dev <dev@dpdk.org>; Stephen Hemminger <stephen@networkplumber.org>
> > Subject: Re: [dpdk-dev] Suggestions for the dpdk stable tree
> > 
> > Hi,
> > I guess over time/releases less people mind the 2.2-stable.
> > But I still see a lot of people referring to 2.2 - so why not giving this
> > thread a ping again.
> > 
> > ack / nack / opinions ?
> 
> Hi Christian,
> 
> We are interested in having a LTS/Stable tree.

I didn't notice this thread, otherwise, I would have commented earlier:
TBH, I have also thought of LTS tree few months before. But I was thinking,
hmm, it's just a library, what's the big deal of maintaining a stable
tree for it. I then hide it deep inside of my mind, silently.

> We have been looking at identifying a maintainer and validation engineer internally to support the effort but haven't be able to finalize that. Once we do we will come back to the mailing list with a proposal and a request for comments.

I would nominate myself as the LTS tree maintainer, if it makes sense
to have one.

> We would probably be looking at 16.04 or even 16.07 as the basis for the LTS at this stage.

Just one opinion from the view of vhost: since 16.07 is a vhost ABI/API
refactoring release, I'd suggest to base on 16.07, and then we could
have less conflicts to apply later bug fix patches.

However, I'm very open to choose any others as the base, say, even v2.2.

	--yliu

> It would be great if we could get support from you or others as well.
> 
> John.
> -- 
> 

Re: Suggestions for the dpdk stable tree

[Mcnamara, John]

> -----Original Message-----
> From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
> Sent: Monday, May 23, 2016 3:22 AM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: Christian Ehrhardt <christian.ehrhardt@canonical.com>; dev
> <dev@dpdk.org>; Stephen Hemminger <stephen@networkplumber.org>; Thomas
> Monjalon <thomas.monjalon@6wind.com>
> Subject: Re: [dpdk-dev] Suggestions for the dpdk stable tree
> 
> > We have been looking at identifying a maintainer and validation engineer
> internally to support the effort but haven't be able to finalize that.
> Once we do we will come back to the mailing list with a proposal and a
> request for comments.
> 
> I would nominate myself as the LTS tree maintainer, if it makes sense to
> have one.

Hi Yuanhan,

Thanks for putting your name forward. I think your experience as the dpdk-next-virtio
maintainer will help with this.


> > We would probably be looking at 16.04 or even 16.07 as the basis for the
> LTS at this stage.
> 
> Just one opinion from the view of vhost: since 16.07 is a vhost ABI/API
> refactoring release, I'd suggest to base on 16.07, and then we could have
> less conflicts to apply later bug fix patches.

Agreed. At this stage 16.07 make more sense.

I'll start a separate discussion thread about how the LTS process would work
to see if we can get some consensus from interested parties.

John.
--