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

[Ori Kam]

> -----Original Message-----
> From: Stephen Hemminger <stephen at networkplumber.org>
> Sent: Wednesday, August 14, 2019 5:56 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 Wed, 14 Aug 2019 06:05:13 +0000
> Ori Kam <orika at mellanox.com> wrote:
> 
> > > -----Original Message-----
> > > From: Ori Kam
> > > Sent: Wednesday, August 14, 2019 8:36 AM
> > > To: Stephen Hemminger <stephen at networkplumber.org>
> > > 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
> > >
> > > 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?
> > >
> >
> > Forgot in my last mail two more reasons I had for this for this:
> > 1. changing to existing function will break API, and will force all applications
> to update date.
> > 2.  2 API are easier to document and explain.
> > 3. the reason stated above that there will be unused parameters in each call.
> 
> New API's are like system calls, they create longer term support overhead.
> It would be good if there was support for this on multiple NIC types.

I don't know the capability of other NICs. I think this is a good feature that can be embrace
and implemented by other NICS (may be they can even have some SW implementation for this
that will still use CPU but will give faster packet rate since they know how their HW works)
Regarding the long term support, I'm sorry but I don't see the longer support issue that important since for this 
exact reason I think a dedicated API is much easer to maintain. Also my be in future there will be 
a new type and then the generic function will have a lot of unused code which is hard to maintain
and debug.

Thanks,
Ori