> -----Original Message-----
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Tuesday, May 20, 2014 11:39 AM
> To: Richardson, Bruce
> Cc: dev at 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.

Reply via email to