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 <mst@xxxxxxxxxx> wrote: > > On Mon, Jan 22, 2018 at 05:34:37PM -0800, Samudrala, Sridhar wrote: > >> On 1/22/2018 4:05 PM, Michael S. Tsirkin wrote: > >> > On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala, Sridhar wrote: > >> > > > > 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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
