On Mon, Jan 22, 2018 at 07:36:32PM -0800, Alexander Duyck wrote:

On Mon, Jan 22, 2018 at 6:04 PM, Michael S. Tsirkin [off-list ref] wrote:

quoted

On Mon, Jan 22, 2018 at 05:34:37PM -0800, Samudrala, Sridhar wrote:

quoted

On 1/22/2018 4:05 PM, Michael S. Tsirkin wrote:

quoted

On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala, Sridhar wrote:

quoted

quoted

quoted

You could probably
even handle the Tx queue selection via a simple eBPF program and map
since the input for whatever is used to select Tx should be pretty
simple, destination MAC, source NUMA node, etc, and the data-set
shouldn't be too large.

That sounds interesting. A separate device might make this kind of setup
a bit easier.  Sridhar, did you look into creating a separate device for
the virtual bond device at all?  It does not have to be in a separate
module, that kind of refactoring can come later, but once we commit to
using the same single device as virtio, we can't change that.

No. I haven't looked into creating a separate device. If we are going to
create a new
device, i guess it has to be of a new device type with its own driver.

Well not necessarily - just a separate netdev ops.
Kind of like e.g. vlans share a driver with the main driver.

Not sure what you meant by vlans sharing a driver with the main driver.
IIUC, vlans are supported via 802.1q driver and  creates a netdev of type
'vlan'
with vlan_netdev_ops

But nothing prevents a single module from registering
multiple ops.

Just to clarify, it seems like what you are suggesting is just adding
the "master" as a separate set of netdev ops or netdevice and to have
virtio spawn two network devices, one slave and one master, if the
BACKUP bit is set. Do I have that right?

Yes, that was my idea.

I am good with the code still living in the virtio driver and
consolidation with other similar implementations and further
improvement could probably happen later as part of some refactor.

Thanks.

- Alex