Date: Sat, 13 Sep 2014 16:04:20 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Hans Petter Selasky <hps@selasky.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Adrian Chadd <adrian@freebsd.org> Subject: Re: svn commit: r271504 - in head/sys: dev/oce dev/vmware/vmxnet3 dev/xen/netfront net netinet ofed/drivers/net/mlx4 Message-ID: <405398541.35874200.1410638660648.JavaMail.root@uoguelph.ca> In-Reply-To: <54149FC4.7020307@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hans Petter Selasky wrote: > On 09/13/14 18:54, Adrian Chadd wrote: > > Hi, > > > > Just for the record: > > > > * I'm glad you're tackling the TSO config stuff; > > * I'm not glad you're trying to pack it into a u_int rather than > > creating a new structure and adding fields for it. > > > > I appreciate that you're trying to rush this in before 10.1, but > > this > > is exactly why things shouldn't be rushed in before release > > deadlines. > > :) > > > > I'd really like to see this be broken out as a structure and the > > bit > > shifting games for what really shouldn't be packed into a u_int > > fixed. > > Otherwise this is going to be deadweight that has to persist past > > 11.0. > > > > Hi Adrian, > > I can make that change for -current, making the new structure and > such. > This change was intended for 10 where there is only one u_int for > this > information. Or do you want me to change that in 10 too? > Well, there are spare fields (if_ispare[4]) in struct ifnet that I believe can be used for new u_ints when MFC'ng a patch that adds fields to struct ifnet in head. (If I have this wrong, someone please correct me.) I'll admit I don't really see an advantage to defining a structure vs just defining a couple of additional u_ints, but so long as the structure doesn't cause alignment issues for any arch, I don't see a problem with a structure. I tend to agree with Adrian that this shouldn't be rushed. (I, personally, think that if_hw_tsomax was poorly chosen, but that is already in use, so I think we need to add to that and not replace it.) I also hope that your testing has included quite a bit of activity on an NFS mount using TSO and the default 64K rsize, wsize, since that is going to generate a bunch of 35 mbuf transmit fragment lists and there is an edge case where the total data length excluding ethernet header is just under 64K (by less than the ethernet header length) where the list must be split by tcp_output() to avoid disaster. rick > --HPS > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?405398541.35874200.1410638660648.JavaMail.root>