[dpdk-dev] [RFC] ethdev: support hairpin queue

[Ori Kam]

Hi Stephen,

> -----Original Message-----
> From: Stephen Hemminger <stephen at networkplumber.org>
> Sent: Tuesday, August 13, 2019 6:46 PM
> To: Ori Kam <orika at mellanox.com>
> Cc: Thomas Monjalon <thomas at monjalon.net>; ferruh.yigit at intel.com;
> arybchenko at solarflare.com; Shahaf Shuler <shahafs at mellanox.com>; Slava
> Ovsiienko <viacheslavo at mellanox.com>; Alex Rosenbaum
> <alexr at mellanox.com>; dev at dpdk.org
> Subject: Re: [dpdk-dev] [RFC] ethdev: support hairpin queue
> 
> On Tue, 13 Aug 2019 13:37:48 +0000
> Ori Kam <orika at mellanox.com> wrote:
> 
> > This RFC replaces RFC[1].
> >
> > The hairpin feature (different name can be forward) acts as "bump on the
> wire",
> > meaning that a packet that is received from the wire can be modified using
> > offloaded action and then sent back to the wire without application
> intervention
> > which save CPU cycles.
> >
> > The hairpin is the inverse function of loopback in which application
> > sends a packet then it is received again by the
> > application without being sent to the wire.
> >
> > The hairpin can be used by a number of different NVF, for example load
> > balancer, gateway and so on.
> >
> > As can be seen from the hairpin description, hairpin is basically RX queue
> > connected to TX queue.
> >
> > During the design phase I was thinking of two ways to implement this
> > feature the first one is adding a new rte flow action. and the second
> > one is create a special kind of queue.
> 
> 
> Life would be easier for users if the hairpin was an attribute
> of queue configuration, not a separate API call.

I was thinking about it. the reason that I split the functions is that they use different
parameters sets. For example the hairpin queue doesn't need memory region while it does need
the hairpin configuration. So in each case hairpin queue / normal queue there will be
parameters that are not in use. I think this is less preferred. What do you think?

Thanks,
Ori