Re: bizarre em + TSO + MSS issue in RELENG_7

On Nov 17, 2007 2:35 PM, Kip Macy <kip.macy_at_gmail.com> wrote:
> On Nov 17, 2007 2:33 PM, Mike Andrews <mandrews_at_bit0.com> wrote:
> > On Sat, 17 Nov 2007, Kip Macy wrote:
> >
> > > On Nov 17, 2007 10:33 AM, Denis Shaposhnikov <dsh_at_vlink.ru> wrote:
> > >> On Sat, 17 Nov 2007 00:42:54 -0500 (EST)
> > >> Mike Andrews <mandrews_at_bit0.com> wrote:
> > >>
> > >>> Has anyone run into problems with MSS not being respected when using
> > >>> TSO, specifically on em cards?
> > >>
> > >> Yes, I wrote about this problem on the beginning of 2007, see
> > >>
> > >>     http://tinyurl.com/3e5ak5
> > >>
> > >
> > > if_em.c:3502
> > >        /*
> > >         * Payload size per packet w/o any headers.
> > >         * Length of all headers up to payload.
> > >         */
> > >        TXD->tcp_seg_setup.fields.mss = htole16(mp->m_pkthdr.tso_segsz);
> > >        TXD->tcp_seg_setup.fields.hdr_len = hdr_len;
> > >
> > >
> > > Please print out the value of tso_segsz here. It appears to be being
> > > set correctly. The only thing I can think of is that t_maxopd is not
> > > correct. As tso_segsz is correct here:
> >
> >
> > It repeatedly prints 1368 during a 1 meg file transfer over a connection
> > with a 1380 MSS.  Any other printf's I can add?  I'm working on a web page
> > with tcpdump / firewall log output illustrating the issue...
>
> Thanks for the quick follow-up. That means that maxopd is not getting
> initialized correctly, which means I'm going to have add some logging
> to tcp_input. Which means it will have to wait until this evening at
> the earliest. This does, however, mean that em is off the hook. It is
> just doing what it is told.

Whew, now I can relax and enjoy my weekend :)

Jack