> On Wed, 15 Nov 2023 08:14:06 -0800 Stephen Hemminger wrote:
> > Jakub is right that in an ideal world, this could all be managed by
> > userspace. But the management of network devices in Linux is a
> > dumpster fire! Every distro invents there own solution, last time I
> > counted there were
On Wed, 15 Nov 2023 08:14:06 -0800 Stephen Hemminger wrote:
> Jakub is right that in an ideal world, this could all be managed by
> userspace. But the management of network devices in Linux is a
> dumpster fire! Every distro invents there own solution, last time
> I counted there were six
On Fri, 10 Nov 2023 12:05:13 -0800
Jakub Kicinski wrote:
> On Fri, 10 Nov 2023 00:43:55 + Long Li wrote:
> > The code above needs to work with and without netvsc (the possible
> > master device) present.
>
> I don't think that's a reasonable requirement for the kernel code.
>
> The
On Fri, 10 Nov 2023 00:43:55 + Long Li wrote:
> The code above needs to work with and without netvsc (the possible
> master device) present.
I don't think that's a reasonable requirement for the kernel code.
The auto-bonding already puts the kernel into business of guessing
policy, which
> Subject: Re: [PATCH net-next v4] hv_netvsc: Mark VF as slave before exposing
> it
> to user-mode
>
> On Wed, 8 Nov 2023 14:56:52 -0800 lon...@linuxonhyperv.com wrote:
> > From: Long Li
> >
> > When a VF is being exposed form the kernel, it should be mark
On Wed, 8 Nov 2023 14:56:52 -0800 lon...@linuxonhyperv.com wrote:
> From: Long Li
>
> When a VF is being exposed form the kernel, it should be marked as "slave"
> before exposing to the user-mode. The VF is not usable without netvsc running
> as master. The user-mode should never see a VF
