A common usage scenario is to bond a vnic like virtio which typically has
only a single rx queue with a VF device that has multiple receive queues.
This is done to do live migration
On Jan 5, 2016 05:47, "Declan Doherty" [off-list ref] wrote:

On 04/12/15 19:18, Eric Kinzie wrote:

quoted

On Fri Dec 04 19:36:09 +0100 2015, Andriy Berestovskyy wrote:

quoted

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);

quoted

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?

Regards,
Andriy

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.

Eric


On Fri, Dec 4, 2015 at 6:14 PM, Stephen Hemminger

quoted

[off-list ref] wrote:

quoted

From: Eric Kinzie <redacted>

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 <redacted>
Signed-off-by: Stephen Hemminger <stephen@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.