On Tue, Jun 06, 2023 at 11:40:58PM +0200, Alexander Bluhm wrote: > On Tue, Jun 06, 2023 at 11:33:36PM +0300, Vitaliy Makkoveev 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. > > In sysctl we have tso in tcp namespace. That's why I wanted tcplro. > And claudio@ asked for a longer name. Let's see if he has an > opinion.
I'm fine with whatever is chosen. I don't like the three letter acronyms used mainly since there are so many. There is LRO, TSO, GSO, UFO, GRO, and many more. I prefer to have an option for HW assisted receive offloading and (if necessary) another for HW assisted send offloading. Send offloading should be implemented in an interface agnostic way like we did for TSO by adding the tcp_chopper. It will benefit also interfaces that don't really support this in HW. Having a button for each and every option does not really fit OpenBSD's philosophy but there is a need to control recieve offload features because they don't work in some network scenarios (e.g. bridging). -- :wq Claudio
