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 <step...@networkplumber.org> > Cc: Thomas Monjalon <tho...@monjalon.net>; ferruh.yi...@intel.com; > arybche...@solarflare.com; Shahaf Shuler <shah...@mellanox.com>; Slava > Ovsiienko <viachesl...@mellanox.com>; Alex Rosenbaum > <al...@mellanox.com>; dev@dpdk.org > Subject: RE: [dpdk-dev] [RFC] ethdev: support hairpin queue > > > > > -----Original Message----- > > From: Stephen Hemminger <step...@networkplumber.org> > > Sent: Wednesday, August 14, 2019 5:56 PM > > To: Ori Kam <or...@mellanox.com> > > Cc: Thomas Monjalon <tho...@monjalon.net>; ferruh.yi...@intel.com; > > arybche...@solarflare.com; Shahaf Shuler <shah...@mellanox.com>; Slava > > Ovsiienko <viachesl...@mellanox.com>; Alex Rosenbaum > > <al...@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 <or...@mellanox.com> wrote: > > > > > > -----Original Message----- > > > > From: Ori Kam > > > > Sent: Wednesday, August 14, 2019 8:36 AM > > > > To: Stephen Hemminger <step...@networkplumber.org> > > > > Cc: Thomas Monjalon <tho...@monjalon.net>; ferruh.yi...@intel.com; > > > > arybche...@solarflare.com; Shahaf Shuler <shah...@mellanox.com>; > > Slava > > > > Ovsiienko <viachesl...@mellanox.com>; Alex Rosenbaum > > > > <al...@mellanox.com>; dev@dpdk.org > > > > Subject: RE: [dpdk-dev] [RFC] ethdev: support hairpin queue > > > > > > > > Hi Stephen, > > > > > > > > > -----Original Message----- > > > > > From: Stephen Hemminger <step...@networkplumber.org> > > > > > Sent: Tuesday, August 13, 2019 6:46 PM > > > > > To: Ori Kam <or...@mellanox.com> > > > > > Cc: Thomas Monjalon <tho...@monjalon.net>; ferruh.yi...@intel.com; > > > > > arybche...@solarflare.com; Shahaf Shuler <shah...@mellanox.com>; > > Slava > > > > > Ovsiienko <viachesl...@mellanox.com>; Alex Rosenbaum > > > > > <al...@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 <or...@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
