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

[Ori Kam <orika@mellanox.com>]

Hi Stephen,

Does my answer resolves your concerns?

Thanks,
Ori

> -----Original Message-----
> From: Ori Kam
> Sent: Thursday, August 15, 2019 7:42 AM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Thomas Monjalon <thomas@monjalon.net>; ferruh.yigit@intel.com;
> arybchenko@solarflare.com; Shahaf Shuler <shahafs@mellanox.com>; Slava
> Ovsiienko <viacheslavo@mellanox.com>; Alex Rosenbaum
> <Alexr@mellanox.com>; dev@dpdk.org
> Subject: RE: [dpdk-dev] [RFC] ethdev: support hairpin queue
> 
> 
> 
> > -----Original Message-----
> > From: Stephen Hemminger <stephen@networkplumber.org>
> > Sent: Wednesday, August 14, 2019 5:56 PM
> > To: Ori Kam <orika@mellanox.com>
> > Cc: Thomas Monjalon <thomas@monjalon.net>; ferruh.yigit@intel.com;
> > arybchenko@solarflare.com; Shahaf Shuler <shahafs@mellanox.com>; Slava
> > Ovsiienko <viacheslavo@mellanox.com>; Alex Rosenbaum
> > <alexr@mellanox.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [RFC] ethdev: support hairpin queue
> >
> > On Wed, 14 Aug 2019 06:05:13 +0000
> > Ori Kam <orika@mellanox.com> wrote:
> >
> > > > -----Original Message-----
> > > > From: Ori Kam
> > > > Sent: Wednesday, August 14, 2019 8:36 AM
> > > > To: Stephen Hemminger <stephen@networkplumber.org>
> > > > Cc: Thomas Monjalon <thomas@monjalon.net>; ferruh.yigit@intel.com;
> > > > arybchenko@solarflare.com; Shahaf Shuler <shahafs@mellanox.com>;
> > Slava
> > > > Ovsiienko <viacheslavo@mellanox.com>; Alex Rosenbaum
> > > > <Alexr@mellanox.com>; dev@dpdk.org
> > > > Subject: RE: [dpdk-dev] [RFC] ethdev: support hairpin queue
> > > >
> > > > Hi Stephen,
> > > >
> > > > > -----Original Message-----
> > > > > From: Stephen Hemminger <stephen@networkplumber.org>
> > > > > Sent: Tuesday, August 13, 2019 6:46 PM
> > > > > To: Ori Kam <orika@mellanox.com>
> > > > > Cc: Thomas Monjalon <thomas@monjalon.net>; ferruh.yigit@intel.com;
> > > > > arybchenko@solarflare.com; Shahaf Shuler <shahafs@mellanox.com>;
> > Slava
> > > > > Ovsiienko <viacheslavo@mellanox.com>; Alex Rosenbaum
> > > > > <alexr@mellanox.com>; dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [RFC] ethdev: support hairpin queue
> > > > >
> > > > > On Tue, 13 Aug 2019 13:37:48 +0000
> > > > > Ori Kam <orika@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