Linux Virtualization - Jan 2018 - [virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

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
>
>> As we are using virtio_net to control and manage the VF data path, it
is not
>> clear to me
>> what is the advantage of creating a new device rather than extending
>> virtio_net to manage
>> the VF datapath via transparent bond mechanism.
>>
>> Thanks
>> Sridhar
> So that XDP redirect actions can differentiate between virtio, PT
> device and the bond. Without it there's no way to redirect
> to virtio specifically.
I guess this usecase is for a guest admin to add bpf programs to VF 
netdev and
redirect frames to virtio.? How does bond enable this feature?


Thanks
Sridhar

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.

> > 
> > > As we are using virtio_net to control and manage the VF data
path, it is not
> > > clear to me
> > > what is the advantage of creating a new device rather than
extending
> > > virtio_net to manage
> > > the VF datapath via transparent bond mechanism.
> > > 
> > > Thanks
> > > Sridhar
> > So that XDP redirect actions can differentiate between virtio, PT
> > device and the bond. Without it there's no way to redirect
> > to virtio specifically.
> I guess this usecase is for a guest admin to add bpf programs to VF netdev
> and
> redirect frames to virtio.
No - this doesn't make much sense IMHO.  The usecase would be VM
bridging where we process packets incoming on one virtio interface, and
transmit them on another one. It was pointed out using a separate master
netdev and making both virtio and PT its slaves would allow redirect
switch to force virtio, without it it won't be possible to force
redirect to virtio.

How important that use-case is, I am not sure.
>? How does bond enable this feature?
> 
> 
> Thanks
> Sridhar
As it's a userspace configuration, I guess for starters we
can punt this to userspace, too.

-- 
MST

On Mon, Jan 22, 2018 at 6:04 PM, Michael S. Tsirkin <mst at redhat.com>
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?

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