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

[Stephen Hemminger]

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.