[EXT] Re: [PATCH v3 1/2] examples/l3fwd: common packet group functionality

[Rahul Bhansali]

Hi,

> -----Original Message-----
> From: Thomas Monjalon <thomas at monjalon.net>
> Sent: Monday, July 4, 2022 3:10 AM
> To: Rahul Bhansali <rbhansali at marvell.com>
> Cc: dev at dpdk.org; David Christensen <drc at linux.vnet.ibm.com>; Ruifeng Wang
> <ruifeng.wang at arm.com>; Bruce Richardson <bruce.richardson at intel.com>;
> Konstantin Ananyev <konstantin.v.ananyev at yandex.ru>; Jerin Jacob
> Kollanukkaran <jerinj at marvell.com>; Akhil Goyal <gakhil at marvell.com>;
> david.marchand at 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 <rbhansali at 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.

> 
> 
>