svn commit: r271504 - in head/sys: dev/oce dev/vmware/vmxnet3 dev/xen/netfront net netinet ofed/drivers/net/mlx4

[Rick Macklem]

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?
> 
> --HPS
> 
> 
> 
Btw, your patch calls sbsndptr() in tcp_output(), which advances
sb_sndptroff and sb_sndptr by the length.
Then it loops around and reduces the length for the case where
there are too many mbufs in the chain.

I don't know this algorithm well enough to know if advancing
sb_sndptroff and sb_sndptr by too much for this case will
cause a problem?

I avoided the question by implementing sbsndmbuf() that was cloned
from sbsndptr() to avoid this when I did my draft patch. It is in
the attached patch, in case it is useful. (It avoids updating
sb_sndptroff and sb_sndptr.)

rick


-------------- next part --------------
A non-text attachment was scrubbed...
Name: tsomaxseg.patch
Type: text/x-patch
Size: 4179 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140913/e3de5480/attachment.bin>