drivers/net/hyperv/netvsc_drv.c | 2 +- include/linux/netdevice.h | 4 ++++ net/core/dev.c | 18 ++++++++++++++++++ 3 files changed, 23 insertions(+), 1 deletion(-)
From: Jason Wang <jasowang@redhat.com>
When netvsc is accelerated by the lower device, we can advertise the
lower device max tso size in order to get better performance.
One example is that when 802.3ad encap is enabled by netvsc, it has a
lower max tso size than 64K. This will lead to software segmentation
of forwarding GSO packet (e.g the one from VM/tap).
This patch help to recover the performance.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Tested-by: Cindy Lu <lulu@redhat.com>
---
drivers/net/hyperv/netvsc_drv.c | 2 +-
include/linux/netdevice.h | 4 ++++
net/core/dev.c | 18 ++++++++++++++++++
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index c41a025c66f0..7af4aa4f4abe 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -2440,7 +2440,7 @@ static int netvsc_vf_changed(struct net_device *vf_netdev, unsigned long event)
* switched over to the VF
*/
if (vf_is_up)
- netif_set_tso_max_size(ndev, vf_netdev->tso_max_size);
+ netif_stacked_transfer_tso_max_size(vf_netdev, ndev);
else
netif_set_tso_max_size(ndev, netvsc_dev->netvsc_gso_max_size);
}
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index adb14db25798..c695a3ffecd8 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -5275,6 +5275,9 @@ void netdev_change_features(struct net_device *dev);
void netif_stacked_transfer_operstate(const struct net_device *rootdev,
struct net_device *dev);
+void netif_stacked_transfer_tso_max_size(const struct net_device *rootdev,
+ struct net_device *dev);
+
netdev_features_t passthru_features_check(struct sk_buff *skb,
struct net_device *dev,
netdev_features_t features);
@@ -5326,6 +5329,7 @@ static inline bool netif_needs_gso(struct sk_buff *skb,
}
void netif_set_tso_max_size(struct net_device *dev, unsigned int size);
+
void netif_set_tso_max_segs(struct net_device *dev, unsigned int segs);
void netif_inherit_tso_max(struct net_device *to,
const struct net_device *from);
diff --git a/net/core/dev.c b/net/core/dev.c
index be97c440ecd5..3bec4284adff 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3306,6 +3306,24 @@ void netif_set_tso_max_size(struct net_device *dev, unsigned int size)
}
EXPORT_SYMBOL(netif_set_tso_max_size);
+/**
+ * netif_stacked_transfer_tso_max_size - transfer tso max size
+ * @rootdev: the root or lower level device to transfer tso max size from
+ * @dev: the device to transfer operstate to
+ *
+ * Transfer tso max size from root to device. This is normally
+ * called when a stacking relationship exists between the root
+ * device and the device(a leaf device).
+ */
+void netif_stacked_transfer_tso_max_size(const struct net_device *rootdev,
+ struct net_device *dev)
+{
+ dev->tso_max_size = rootdev->tso_max_size;
+ netif_set_gso_max_size(dev, READ_ONCE(rootdev->gso_max_size));
+ netif_set_gso_ipv4_max_size(dev, READ_ONCE(rootdev->gso_ipv4_max_size));
+}
+EXPORT_SYMBOL(netif_stacked_transfer_tso_max_size);
+
/**
* netif_set_tso_max_segs() - set the max number of segs supported for TSO
* @dev: netdev to update
--
2.45.0
On Fri, 18 Jul 2025 14:17:55 +0800 Cindy Lu wrote: > Subject: [PATCH RESEND] netvsc: transfer lower device max tso size You say RESEND but I don't see a link to previous posting anywhere. I'd rather we didn't extend the magic behavior of hyperv/netvsc any further. We have enough problems with it.
On Tue, Jul 22, 2025 at 7:28 AM Jakub Kicinski <kuba@kernel.org> wrote: > > On Fri, 18 Jul 2025 14:17:55 +0800 Cindy Lu wrote: > > Subject: [PATCH RESEND] netvsc: transfer lower device max tso size > > You say RESEND but I don't see a link to previous posting anywhere. > > I'd rather we didn't extend the magic behavior of hyperv/netvsc any > further. Are you referring to the netdev coupling model of the VF acceleration? > We have enough problems with it. > But this fixes a real problem, otherwise nested VM performance will be broken due to the GSO software segmentation. Thanks
On Tue, 22 Jul 2025 09:04:20 +0800 Jason Wang wrote: > On Tue, Jul 22, 2025 at 7:28 AM Jakub Kicinski <kuba@kernel.org> wrote: > > On Fri, 18 Jul 2025 14:17:55 +0800 Cindy Lu wrote: > > > Subject: [PATCH RESEND] netvsc: transfer lower device max tso size > > > > You say RESEND but I don't see a link to previous posting anywhere. Someone should respond to this part, please. > > I'd rather we didn't extend the magic behavior of hyperv/netvsc any > > further. > > Are you referring to the netdev coupling model of the VF acceleration? Yes, it tries to apply whole bunch of policy automatically in the kernel. > > We have enough problems with it. > > 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.kernel.org/all/1752870014-28909-1-git-send-email-haiyangz@linux.microsoft.com/
On Tue, Jul 22, 2025 at 9:18 AM Jakub Kicinski <kuba@kernel.org> wrote: > > On Tue, 22 Jul 2025 09:04:20 +0800 Jason Wang wrote: > > On Tue, Jul 22, 2025 at 7:28 AM Jakub Kicinski <kuba@kernel.org> wrote: > > > On Fri, 18 Jul 2025 14:17:55 +0800 Cindy Lu wrote: > > > > Subject: [PATCH RESEND] netvsc: transfer lower device max tso size > > > > > > You say RESEND but I don't see a link to previous posting anywhere. > > Someone should respond to this part, please. > > > > I'd rather we didn't extend the magic behavior of hyperv/netvsc any > > > further. > > > > Are you referring to the netdev coupling model of the VF acceleration? > > Yes, it tries to apply whole bunch of policy automatically in > the kernel. > > > > We have enough problems with it. > > > > 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.kernel.org/all/1752870014-28909-1-git-send-email-haiyangz@linux.microsoft.com/ Btw, if I understand this correctly. This is for future development so it's not a blocker for this patch? Thanks >
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.kernel.org/all/1752870014-28909-1-git-send-email-haiyangz@linux.microsoft.com/ > > 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).
Hi Jakub, On Wed, Jul 23, 2025 at 11:05 PM Jakub Kicinski <kuba@kernel.org> wrote: > > 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.kernel.org/all/1752870014-28909-1-git-send-email-haiyangz@linux.microsoft.com/ > > > > 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). > Please let me know if you want to merge this patch or not. If not, how to proceed. Thanks
On Thu, 31 Jul 2025 09:07:27 +0800 Jason Wang wrote: > > > 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). > > > > Please let me know if you want to merge this patch or not. If not, how > to proceed. As is its definitely not getting merged. Please make it look less burdensome or fix it in user space(!!).
On Tue, Jul 22, 2025 at 9:18 AM Jakub Kicinski <kuba@kernel.org> wrote: > > On Tue, 22 Jul 2025 09:04:20 +0800 Jason Wang wrote: > > On Tue, Jul 22, 2025 at 7:28 AM Jakub Kicinski <kuba@kernel.org> wrote: > > > On Fri, 18 Jul 2025 14:17:55 +0800 Cindy Lu wrote: > > > > Subject: [PATCH RESEND] netvsc: transfer lower device max tso size > > > > > > You say RESEND but I don't see a link to previous posting anywhere. > > Someone should respond to this part, please. > Hi Jakub, sorry for the confusion. I previously sent this mail (https://lore.kernel.org/all/20250718060615.237986-1-lulu@redhat.com/) to the wrong mailing list, so I'm resended it here. I've also submitted a v2 of this patch: https://lore.kernel.org/all/20250718082909.243488-1-lulu@redhat.com/ Sorry again for the mix-up. thanks cindy > > > I'd rather we didn't extend the magic behavior of hyperv/netvsc any > > > further. > > > > Are you referring to the netdev coupling model of the VF acceleration? > > Yes, it tries to apply whole bunch of policy automatically in > the kernel. > > > > We have enough problems with it. > > > > 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.kernel.org/all/1752870014-28909-1-git-send-email-haiyangz@linux.microsoft.com/ >
On Tue, Jul 22, 2025 at 10:04 AM Cindy Lu <lulu@redhat.com> wrote: > > On Tue, Jul 22, 2025 at 9:18 AM Jakub Kicinski <kuba@kernel.org> wrote: > > > > On Tue, 22 Jul 2025 09:04:20 +0800 Jason Wang wrote: > > > On Tue, Jul 22, 2025 at 7:28 AM Jakub Kicinski <kuba@kernel.org> wrote: > > > > On Fri, 18 Jul 2025 14:17:55 +0800 Cindy Lu wrote: > > > > > Subject: [PATCH RESEND] netvsc: transfer lower device max tso size > > > > > > > > You say RESEND but I don't see a link to previous posting anywhere. > > > > Someone should respond to this part, please. > > > Hi Jakub, > sorry for the confusion. I previously sent this mail > (https://lore.kernel.org/all/20250718060615.237986-1-lulu@redhat.com/) > to the wrong mailing list, so I'm resended it here. > I've also submitted a v2 of this patch: > https://lore.kernel.org/all/20250718082909.243488-1-lulu@redhat.com/ > Sorry again for the mix-up. > thanks > > cindy > > > > > I'd rather we didn't extend the magic behavior of hyperv/netvsc any > > > > further. > > > > > > Are you referring to the netdev coupling model of the VF acceleration? > > > > Yes, it tries to apply whole bunch of policy automatically in > > the kernel. > > > > > > We have enough problems with it. > > > > > > 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.kernel.org/all/1752870014-28909-1-git-send-email-haiyangz@linux.microsoft.com/ I'm also including Stephen Hemminger and Long Li in this thread and would greatly appreciate any suggestions. Thanks cindy > >
© 2016 - 2025 Red Hat, Inc.