On Wed, Jun 07, 2023 at 12:59:11PM +0300, Vitaliy Makkoveev wrote: > On Wed, Jun 07, 2023 at 10:19:32AM +1000, David Gwynne wrote: > > > > > > > On 7 Jun 2023, at 06:33, Vitaliy Makkoveev <m...@openbsd.org> wrote: > > > > > >> On 6 Jun 2023, at 20:29, Alexander Bluhm <alexander.bl...@gmx.net> wrote: > > >> > > >> On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkoveev wrote: > > >>> On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote: > > >>>> Hi, > > >>>> > > >>>> I would suggest to rename ifconfig tcprecvoffload to tcplro. Maybe > > >>>> it's just because I had to type that long name too often. > > >>>> > > >>>> With that we have consistent naming: > > >>>> # ifconfig ix0 tcplro > > >>>> # sysctl net.inet.tcp.tso=1 > > >>>> > > >>>> Also the coresponding flag are named LRO. > > >>>> # ifconfig ix1 hwfeatures > > >>>> ix1: flags=2008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LRO> mtu 1500 > > >>>> > > >>>> hwfeatures=71b7<CSUM_IPv4,CSUM_TCPv4,CSUM_UDPv4,VLAN_MTU,VLAN_HWTAGGING,CSUM_TCPv6,CSUM_UDPv6,TSOv4,TSOv6,LRO> > > >>>> hardmtu 9198 > > >>>> > > >>>> The feature is quite new, so I have no backward compatiblity concerns. > > >>>> > > >>>> ok? > > >>>> > > >>> > > >>> Could you name it "lro" like FreeBSD uses? > > >> > > >> When I started with this, LRO and TSO were unknown to me. So with > > >> TCP prefix it may be clearer to users where the feature belongs. > > >> > > >> Naming is hard. > > > > > > Yeah, naming is definitely hard. I propose to use lro because it is > > > already used for the same purpose by FreeBSD, so the same name helps > > > to avoid confusion. > > > > > > lro If the driver supports tcp(4) large receive offloading, > > > enable LRO on the interface. > > > > > > Also, we have used "tso" keyword for tcp segmentation offloading for > > > the same reason, until it became global net.inet.tcp.tso. > > > > Is it going to be used to enable lro for udp and other protocols as well? > > Why not? We have tso feature system wide, so why don't have receive > offloading feature global for all supported protocols? Especially since > I suspect this control will be moved from ifconfig to global > net.inet.tcp.lro like net.inet.tcp.tso.
Maybe we can make lro the default, and then move it to net.inet.tcp.lro. But I like to see another driver to implement it first. > However, I'm not the fan of original "tcprecvoffload" and like shorter > naming. Can we use ifconfig tcplro for now? + it only affects TCP + user see that it is related to TCP + it is not a 3 letter abrevation claudio does not like + it is shorter than tcprecvoffload cons - FreeBSD calls it lro bluhm