> -----Original Message-----
> From: Jakub Kicinski <[email protected]>
> Sent: Wednesday, July 23, 2025 11:06 AM
> To: Jason Wang <[email protected]>
> Cc: Cindy Lu <[email protected]>; KY Srinivasan <[email protected]>; Haiyang
> Zhang <[email protected]>; Wei Liu <[email protected]>; Dexuan Cui
> <[email protected]>; Andrew Lunn <[email protected]>; David S.
> Miller <[email protected]>; Eric Dumazet <[email protected]>; Paolo
> Abeni <[email protected]>; Simon Horman <[email protected]>; Michael Kelley
> <[email protected]>; Shradha Gupta <[email protected]>;
> Kees Cook <[email protected]>; Stanislav Fomichev <[email protected]>;
> Kuniyuki Iwashima <[email protected]>; Alexander Lobakin
> <[email protected]>; Guillaume Nault <[email protected]>; Joe
> Damato <[email protected]>; Ahmed Zaki <[email protected]>; open
> list:Hyper-V/Azure CORE AND DRIVERS <[email protected]>; open
> list:NETWORKING DRIVERS <[email protected]>; open list <linux-
> [email protected]>
> Subject: [EXTERNAL] Re: [PATCH RESEND] netvsc: transfer lower device max
> tso size
>
> On Wed, 23 Jul 2025 14:00:47 +0800 Jason Wang wrote:
> > > > But this fixes a real problem, otherwise nested VM performance will
> be
> > > > broken due to the GSO software segmentation.
> > >
> > > Perhaps, possibly, a migration plan can be devised, away from the
> > > netvsc model, so we don't have to deal with nuggets of joy like:
> > >
> https://lore.ker/
> nel.org%2Fall%2F1752870014-28909-1-git-send-email-
> haiyangz%40linux.microsoft.com%2F&data=05%7C02%7Chaiyangz%40microsoft.com%
> 7C27aa73c4b6e9446c7f6508ddc9fa6053%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> 7C0%7C638888799449774753%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI
> lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C
> %7C%7C&sdata=HYX4dDie8QlEepzwPiiI3eYASe7WN5o%2BWTXmMGoyFOM%3D&reserved=0
> >
> > Btw, if I understand this correctly. This is for future development so
> > it's not a blocker for this patch?
>
> Not a blocker, I'm just giving an example of the netvsc auto-weirdness
> being a source of tech debt and bugs. Commit d7501e076d859d is another
> recent one off the top of my head. IIUC systemd-networkd is broadly
> deployed now. It'd be great if there was some migration plan for moving
> this sort of VM auto-bonding to user space (with the use of the common
> bonding driver, not each hypervisor rolling its own).
Actually, we had used the common bonding driver 9 years ago. But it's
replaced by this kernel/netvsc based "transparent" bonding mode. See
the patches listed below.
The user mode bonding scripts were unstable, and difficult to deliver
& update for various distros. So Stephen developed the new "transparent"
bonding mode, which greatly improves the situation.
@Stephen Hemminger <[email protected]>, in case he wants to
add more regarding the history.
Related patches:
author Haiyang Zhang <[email protected]> 2016-07-11 17:06:42 -0700
committer David S. Miller <[email protected]> 2016-07-12 10:41:53
-0700
commit 178cd55f086629cf0bad9c66c793a7e2bcc3abb6 (patch)
tools: hv: Add a script to help bonding synthetic and VF NICs
author stephen hemminger <[email protected]> 2017-08-01 19:58:55
-0700
committer David S. Miller <[email protected]> 2017-08-02 16:55:33
-0700
commit 12aa7469d101e139b3728e540884bc7d72dca70a (patch)
netvsc: remove bonding setup script
No longer needed, now all managed by transparent VF logic.
Thanks,
- Haiyang
