Linux Virtualization - Apr 2018 - [PATCH v7 net-next 4/4] netvsc: refactor notifier/event handling code to use the failover framework

On Mon, 23 Apr 2018 20:24:56 +0300
"Michael S. Tsirkin" <mst at redhat.com> wrote:
> On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > > >
> > > >I will NAK patches to change to common code for netvsc
especially the
> > > >three device model.  MS worked hard with distro vendors to
support transparent
> > > >mode, ans we really can't have a new model; or do
backport.
> > > >
> > > >Plus, DPDK is now dependent on existing model.    
> > > 
> > > Sorry, but nobody here cares about dpdk or other similar
oddities.
> > 
> > The network device model is a userspace API, and DPDK is a userspace
application.
> 
> It is userspace but are you sure dpdk is actually poking at netdevs?
> AFAIK it's normally banging device registers directly.
> 
> > You can't go breaking userspace even if you don't like the
application.
> 
> Could you please explain how is the proposed patchset breaking
> userspace? Ignoring DPDK for now, I don't think it changes the
userspace
> API at all.
> 
The DPDK has a device driver vdev_netvsc which scans the Linux network devices
to look for Linux netvsc device and the paired VF device and setup the
DPDK environment.  This setup creates a DPDK failsafe (bondingish) instance
and sets up TAP support over the Linux netvsc device as well as the Mellanox
VF device.

So it depends on existing 2 device model. You can't go to a 3 device model
or start hiding devices from userspace.

Also, I am working on associating netvsc and VF device based on serial number
rather than MAC address. The serial number is how Windows works now, and it
makes
sense for Linux and Windows to use the same mechanism if possible.

On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger
wrote:
> On Mon, 23 Apr 2018 20:24:56 +0300
> "Michael S. Tsirkin" <mst at redhat.com> wrote:
> 
> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
> > > > >
> > > > >I will NAK patches to change to common code for netvsc
especially the
> > > > >three device model.  MS worked hard with distro vendors
to support transparent
> > > > >mode, ans we really can't have a new model; or do
backport.
> > > > >
> > > > >Plus, DPDK is now dependent on existing model.    
> > > > 
> > > > Sorry, but nobody here cares about dpdk or other similar
oddities.
> > > 
> > > The network device model is a userspace API, and DPDK is a
userspace application.
> > 
> > It is userspace but are you sure dpdk is actually poking at netdevs?
> > AFAIK it's normally banging device registers directly.
> > 
> > > You can't go breaking userspace even if you don't like
the application.
> > 
> > Could you please explain how is the proposed patchset breaking
> > userspace? Ignoring DPDK for now, I don't think it changes the
userspace
> > API at all.
> > 
> 
> The DPDK has a device driver vdev_netvsc which scans the Linux network
devices
> to look for Linux netvsc device and the paired VF device and setup the
> DPDK environment.  This setup creates a DPDK failsafe (bondingish) instance
> and sets up TAP support over the Linux netvsc device as well as the
Mellanox
> VF device.
> 
> So it depends on existing 2 device model. You can't go to a 3 device
model
> or start hiding devices from userspace.
Okay so how does the existing patch break that? IIUC does not go to
a 3 device model since netvsc calls failover_register directly.
> Also, I am working on associating netvsc and VF device based on serial
number
> rather than MAC address. The serial number is how Windows works now, and it
makes
> sense for Linux and Windows to use the same mechanism if possible.
Maybe we should support same for virtio ...
Which serial do you mean? From vpd?

I guess you will want to keep supporting MAC for old hypervisors?

It all seems like a reasonable thing to support in the generic core.

-- 
MST

On Mon, Apr 23, 2018 at 10:56 AM, Michael S. Tsirkin <mst at redhat.com>
wrote:
> On Mon, Apr 23, 2018 at 10:44:40AM -0700, Stephen Hemminger wrote:
>> On Mon, 23 Apr 2018 20:24:56 +0300
>> "Michael S. Tsirkin" <mst at redhat.com> wrote:
>>
>> > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote:
>> > > > >
>> > > > >I will NAK patches to change to common code for
netvsc especially the
>> > > > >three device model.  MS worked hard with distro
vendors to support transparent
>> > > > >mode, ans we really can't have a new model; or
do backport.
>> > > > >
>> > > > >Plus, DPDK is now dependent on existing model.
>> > > >
>> > > > Sorry, but nobody here cares about dpdk or other similar
oddities.
>> > >
>> > > The network device model is a userspace API, and DPDK is a
userspace application.
>> >
>> > It is userspace but are you sure dpdk is actually poking at
netdevs?
>> > AFAIK it's normally banging device registers directly.
>> >
>> > > You can't go breaking userspace even if you don't
like the application.
>> >
>> > Could you please explain how is the proposed patchset breaking
>> > userspace? Ignoring DPDK for now, I don't think it changes the
userspace
>> > API at all.
>> >
>>
>> The DPDK has a device driver vdev_netvsc which scans the Linux network
devices
>> to look for Linux netvsc device and the paired VF device and setup the
>> DPDK environment.  This setup creates a DPDK failsafe (bondingish)
instance
>> and sets up TAP support over the Linux netvsc device as well as the
Mellanox
>> VF device.
>>
>> So it depends on existing 2 device model. You can't go to a 3
device model
>> or start hiding devices from userspace.
>
> Okay so how does the existing patch break that? IIUC does not go to
> a 3 device model since netvsc calls failover_register directly.
>
>> Also, I am working on associating netvsc and VF device based on serial
number
>> rather than MAC address. The serial number is how Windows works now,
and it makes
>> sense for Linux and Windows to use the same mechanism if possible.
>
> Maybe we should support same for virtio ...
> Which serial do you mean? From vpd?
>
> I guess you will want to keep supporting MAC for old hypervisors?
>
> It all seems like a reasonable thing to support in the generic core.
That's the reason why I chose explicit identifier rather than rely on
MAC address to bind/pair a device. MAC address can change. Even if it
can't, malicious guest user can fake MAC address to skip binding.

-Siwei

>
> --
> MST