Hi, > -----Original Message----- > From: Thomas Monjalon <tho...@monjalon.net> > Sent: Monday, July 4, 2022 3:10 AM > To: Rahul Bhansali <rbhans...@marvell.com> > Cc: dev@dpdk.org; David Christensen <d...@linux.vnet.ibm.com>; Ruifeng Wang > <ruifeng.w...@arm.com>; Bruce Richardson <bruce.richard...@intel.com>; > Konstantin Ananyev <konstantin.v.anan...@yandex.ru>; Jerin Jacob > Kollanukkaran <jer...@marvell.com>; Akhil Goyal <gak...@marvell.com>; > david.march...@redhat.com > Subject: [EXT] Re: [PATCH v3 1/2] examples/l3fwd: common packet group > functionality > > External Email > > ---------------------------------------------------------------------- > 23/06/2022 11:38, Rahul Bhansali: > > This will make the packet grouping function common, so that other > > examples can utilize as per need. > > > > For each architecture sse/neon/altivec, port group headers will be > > created under examples/common/<arch>. > > > > Signed-off-by: Rahul Bhansali <rbhans...@marvell.com> > > --- > > Changes in v3: Created common port-group headers for architectures > > sse/neon/altivec as suggested by Konstantin. > > > > Changes in v2: New patch to address review comment. > > > > examples/common/altivec/port_group.h | 48 +++++++++ > > examples/common/neon/port_group.h | 50 ++++++++++ > > examples/common/pkt_group.h | 139 +++++++++++++++++++++++++++ > > examples/common/sse/port_group.h | 47 +++++++++ > > examples/l3fwd/Makefile | 5 +- > > examples/l3fwd/l3fwd.h | 2 - > > examples/l3fwd/l3fwd_altivec.h | 37 +------ > > examples/l3fwd/l3fwd_common.h | 129 +------------------------ > > examples/l3fwd/l3fwd_neon.h | 39 +------- > > examples/l3fwd/l3fwd_sse.h | 36 +------ > > examples/meson.build | 2 +- > > OK you move code from l3fwd to another place. > That's probably a step in the right direction. > What about taking the extra step of making it an EAL API? Thanks for the suggestion. These changes are specific to fast path and I think EAL is more focused towards control path (Correct me if I am wrong). Instead of EAL API, we can have it in library, but currently these are very few changes to form a library. Later in future if we can identify more such common APIs then we can form a library around these specific things, so that more examples/app/library can use it. Please suggest if this makes sense.
> > >
