>> however, after fixing things so the initial cwind isn't hosed, i get a
>> little better story:
>
> so, actually, i think this is the root cause. the intial cwind is misset for
> loopback.
> i but that the symptom folks will see is that /net/tcp/stats shows
> fragmentation when
> performance
> * the SYN-ACK needs to send the local mss, not echo the remote mss.
> asymmetry is "fine" in the other side, even if ip/tcp.c isn't smart enough to
> keep tx and rx mss seperate. (scare quotes = untested, there may be
> some performance niggles if the sender is sending legal packets larger than
On Sun May 10 10:58:55 PDT 2015, 0in...@gmail.com wrote:
> >> however, after fixing things so the initial cwind isn't hosed, i get a
> >> little better story:
> >
> > so, actually, i think this is the root cause. the intial cwind is misset
> > for loopback.
> > i but that the symptom folks will
> 2.a) tcpiput() gets a ACK packet for Listening connection, calls
> tcpincoming().
> 2.b) tcpincoming() looks in limbo, finds lp. and makes new connection.
> 3.c) initialize our connections tcb->mss.
>
> > * the setting of tcb->mss in tcpincoming is not correct, tcp->mss is
> > set by SYN, not b
how is this the opposite? your patch shows the tcb->mss init being removed
completely from tcpincoming().
- /* our sending max segment size cannot be bigger than what he asked for
*/
- if(lp->mss != 0 && lp->mss < tcb->mss) {
- tcb->mss = lp->mss;
- tpriv
On Sun May 10 14:36:15 PDT 2015, cinap_len...@felloff.net wrote:
> how is this the opposite? your patch shows the tcb->mss init being removed
> completely from tcpincoming().
>
> - /* our sending max segment size cannot be bigger than what he asked for
> */
> - if(lp->mss != 0 && lp->ms
