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? Thanks, Ori
