Re: [RFC PATCH v3 0/3] Enable virtio_net to act as a backup for a passthru device

["Samudrala, Sridhar" <sridhar.samudrala@intel.com>]

On 2/21/2018 6:02 PM, Jakub Kicinski wrote:
> On Wed, 21 Feb 2018 12:57:09 -0800, Alexander Duyck wrote:
> > > I don't see why the team cannot be there always.
> > It is more the logistical nightmare. Part of the goal here was to work
> > with the cloud base images that are out there such as
> > https://alt.fedoraproject.org/cloud/. With just the kernel changes the
> > overhead for this stays fairly small and would be pulled in as just a
> > standard part of the kernel update process. The virtio bypass only
> > pops up if the backup bit is present. With the team solution it
> > requires that the base image use the team driver on virtio_net when it
> > sees one. I doubt the OSVs would want to do that just because SR-IOV
> > isn't that popular of a case.
> IIUC we need to monitor for a "backup hint", spawn the master, rename it
> to maintain backwards compatibility with no-VF setups and enslave the VF
> if it appears.
>
> All those sound possible from user space, the advantage of the kernel
> solution right now is that it has more complete code.
>
> Am I misunderstanding?

I think there is some misunderstanding about the exact requirement and 
the usecase
we are trying to solve.  If the Guest is allowed to do this 
configuration, we already have
a solution with either bond/team based user space configuration.

This is to enable cloud service providers to provide a accelerated 
datapath by simply
letting to tenants to get their own images with the only requirement to 
enable their
kernels with newer virtio_net driver with BACKUP support and the VF driver.

To recap from an earlier thread, here is a response from Stephen that 
talks about the
requirement for the netvsc solution and we would like to provide similar 
solution for
KVM based cloud deployments.

> The requirement with Azure accelerated network was that a stock 
distribution image from the
> store must be able to run unmodified and get accelerated networking.
>  Not sure if other environments need to work the same, but it would 
be nice.
>  That meant no additional setup scripts (aka no bonding) and also it must
> work transparently with hot-plug. Also there are diverse set of 
environments:
> openstack, cloudinit, network manager and systemd. The solution had 
to not depend
> on any one of them, but also not break any of them.

Thanks
Sridhar