Re: [dpdk-dev] [PATCH 0/4] New library: rte_distributor

["Richardson, Bruce" <bruce.richardson@intel.com>]

> -----Original Message-----
> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Tuesday, May 20, 2014 11:39 AM
> To: Richardson, Bruce
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/4] New library: rte_distributor
> 
> >
> This sounds an awful lot like the team and bonding drivers.  Why implement this
> as a separate application accessible api, rather than a stacked PMD?  If you do
> the latter then existing applications could concievably change their
> configurations to use this technology and gain the benefit of load distribution
> without having to alter the application to use a new api.
> 

I'm not sure I see the similarity with the bonded driver, which merges multiple ports into a single logical port, i.e. you pull packets from a single source which is actually pull packets from possibly multiple sources behind the scenes, whereas this takes packets from an unknown source and distributes them among a set of workers a single packet at a time. (While handling single packets is slower than handling packet bursts, it is something that is sometimes needed to support existing code which may not be written to work with packet bursts.) 

The load balancing is also more dynamic than that done by existing mechanisms, since no calculation is done on the packets or the packet metadata to assign a packet to a worker - instead if a particular flow tag is not in-flight with a worker, the next packet with that tag goes to the next available worker. In this way, the library also takes care of ensuring that packets from a single flow are maintained in order, and provides a mechanism to have the packets passed back to the distributor thread when done, for further processing there, e.g. rescheduling a second time, or other actions. 

While in certain circumstances an ethdev rx/tx API could be used (and it is something we have thought about and may well add to this library in future), there are certain requirements that cannot be met by just making this a stacked ethdev/PMD:
* not all packets come from an rx_burst call on another PMD, especially where the tags on the packets need to be computed by software
* the rx_burst API call provides no way to pass back packets to the source when finished.