On Wed, Jun 07, 2023 at 02:49:07PM +0300, Vitaliy Makkoveev wrote: > On Wed, Jun 07, 2023 at 01:29:09PM +0200, Alexander Bluhm wrote: > > 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 > > > > Feel free to use tcplro.
Do so. OK jan@
