[dpdk-dev] [PATCH 6/8] bond: handle slaves with fewer queues than bonding device
declan.doherty at intel.com
Tue Jan 5 14:46:05 CET 2016
On 04/12/15 19:18, Eric Kinzie wrote:
> On Fri Dec 04 19:36:09 +0100 2015, Andriy Berestovskyy wrote:
>> Hi guys,
>> I'm not quite sure if we can support less TX queues on a slave that easy:
>>> queue_id = bond_slave_txqid(internals, i, bd_tx_q->queue_id);
>>> num_tx_slave = rte_eth_tx_burst(slaves[i], queue_id,
>>> slave_bufs[i], slave_nb_pkts[i]);
>> It seems that two different lcores might end up writing to the same
>> slave queue at the same time, isn't it?
> Andriy, I think you're probably right about this. Perhaps it should
> instead refuse to add or refuse to activate a slave with too few
> tx queues. Could probably fix this with another layer of buffering
> so that an lcore with a valid tx queue could pick up the mbufs later,
> but this doesn't seem very appealing.
>> On Fri, Dec 4, 2015 at 6:14 PM, Stephen Hemminger
>> <stephen at networkplumber.org> wrote:
>>> From: Eric Kinzie <ekinzie at brocade.com>
>>> In the event that the bonding device has a greater number of tx and/or rx
>>> queues than the slave being added, track the queue limits of the slave.
>>> On receive, ignore queue identifiers beyond what the slave interface
>>> can support. During transmit, pick a different queue id to use if the
>>> intended queue is not available on the slave.
>>> Signed-off-by: Eric Kinzie <ekinzie at brocade.com>
>>> Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
I don't there is any straight forward way of supporting slaves with
different numbers of queues, the initial library was written with the
assumption that the number of tx/rx queues would always be the same on
each slave. This is why,when a slave is added to a bonded device we
reconfigure the queues. For features like RSS we have to have the same
number of rx queues otherwise the flow distribution to an application
could change in the case of a fail over event. Also by supporting
different numbers of queues between slaves we would be no longer be
supporting the standard behavior of ethdevs in DPDK were we expect that
by using different queues we don't require locking to be thread safe.
More information about the dev