netfront: fix the support for disabling LRO at boot time

[dfr]

Summary

The driver has a tunable hw.xn.enable_lro which is intended to control
whether LRO is enabled. This is currently non-functional - even if its
set to zero, the driver still requests LRO support from the backend.
This change fixes the feature so that if enable_lro is set to zero, LRO
no longer appears in the interface capabilities and LRO is not requested
from the backend.

PR: 273046
MFC after: 1 week

[ehem_freebsd_m5p.com]

This looks plausible. Likely it mostly amounts to a debugging tool since you would basically never want this in anything approximating a real world situation.

[dfr]

In D41439#943930, @ehem_freebsd_m5p.com wrote:

This looks plausible. Likely it mostly amounts to a debugging tool since you would basically never want this in anything approximating a real world situation.

Whether or not its a debugging tool, its currently broken. This change allows a user to disable LRO at boot time which (for me) is a useful workaround for using this driver in VMs with forwarding enabled.

[royger]

I will look in more detail on Monday when I'm back from PTO, but overall I agree it should be fixed. I will also look into possible solutions to detect when forwarding is enabled and disable LRO automatically.

[royger]

Would it be simpler to not set IFCAP_LRO in the if_setcapenable() call on create_netdev() if xn_enable_lro is false? I think that way we would avoid exposing feature-gso-tcpv4 on xenstore and you won't need to modify talk_to_backend().

sys/dev/xen/netfront/netfront.c

2080

I think strictly speaking you shouldn't need to modify this, as setting the feature in available capabilities is fine, but it must not be set in capenable.

[dfr]

Rebased and simplified based on review feedback.

[dfr]

In D41439#946716, @royger wrote:

Would it be simpler to not set IFCAP_LRO in the if_setcapenable() call on create_netdev() if xn_enable_lro is false? I think that way we would avoid exposing feature-gso-tcpv4 on xenstore and you won't need to modify talk_to_backend().

Great idea - that worked really well and simplifies the diff.

[royger]

Are you fine with committing it yourself? Might be worth requesting for backport to the releng 14.0 branch, as it's a low risk fix IMO.

[dfr]

I'll land it shortly - I also plan to merge it to stable/14 and stable/13. I'll see what re@ thinks about releng/14.0.