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.

Reply via email to