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@

Reply via email to