Agreed on both points. I'll submit a patchset to remove the l2fwd_fork example and its user-guide, so it doesn't appear that DPDK supports this model. If anyone on the ML disagrees, they can respond here or on the patch thread.
> -----Original Message----- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Friday, July 27, 2018 11:00 AM > To: Thomas Monjalon <tho...@monjalon.net> > Cc: Eads, Gage <gage.e...@intel.com>; Burakov, Anatoly > <anatoly.bura...@intel.com>; dev@dpdk.org; Richardson, Bruce > <bruce.richard...@intel.com>; jerin.ja...@caviumnetworks.com; Yigit, Ferruh > <ferruh.yi...@intel.com>; hemant.agra...@nxp.com; Ananyev, Konstantin > <konstantin.anan...@intel.com>; Olivier Matz <olivier.m...@6wind.com> > Subject: Re: DPDK and forked processes > > On Fri, 27 Jul 2018 17:03:48 +0200 > Thomas Monjalon <tho...@monjalon.net> wrote: > > > 27/07/2018 15:46, Eads, Gage: > > > As this discussion has broad implications for DPDK, is it a good > > > candidate for > a techboard meeting topic? > > > > We can discuss it in techboard, but usually we prefer discussing > > topics whose resolution is not clear. > > In this case, I think everybody agree with Anatoly, isn't it? > > I would prefer that decisions like this be done by rough consensus on the > mailing > list. > > As far as applications messing with internals, in reality any application can > change anything. Just don't come crying to DPDK community for help. >
