Date: Tue, 27 Jun 2017 09:04:26 +0000 From: "Youssef GHORBAL" <youssef.ghorbal@pasteur.fr> To: Navdeep Parhar <nparhar@gmail.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: Sporadic TCP/RST sent to client Message-ID: <C8872FC3-E022-4D4D-B766-57F42312B261@pasteur.fr> In-Reply-To: <CAPFoGT8sthFOm=vOiFb9%2B2BM=%2BBqtREz1SrOm_UiVge81CrYrw@mail.gmail.com> References: <84CB0795-B28E-46DF-9593-4C1BAAB7DDF5@pasteur.fr> <CAPFoGT8sthFOm=vOiFb9%2B2BM=%2BBqtREz1SrOm_UiVge81CrYrw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[...] >> I've read about netisr work and I was under the impression that e= ven if it's SMP enabled it was made to keep prorocol ordering. >>=20 >> What's the expected behaviour in this scenario on the netisr side= ? >> How can I push the investigation further ? >=20 > I think you've already figured out the situation here -- the PSH/ACK is l= ikely > being handled before the ACK for the SYN because they arrived on differen= t > interfaces. There is nothing in netisr dispatch that will maintain proto= col > ordering in this case. Navdeep, thank you for you feedback. I don't get the fact that netisr is no= t lagg "aware" (if I may say) I understand that netisr dispatch can't maintain ordering if NICs are treat= ed separetly. But when they are enslaved in a "lagg", from the point of the= view of the lagg interface itself, packets arrive ordred and I expect the = system to handle it correctly. The fact is that it is actually handled corr= ectly in most cases but not when packets are really "close" (under 10 micro= seconds) Maybe the default sysctl settings are not meant to handle this corner case,= but I did'nt find anything regarding this in documentation. Youssef Ghorbal=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C8872FC3-E022-4D4D-B766-57F42312B261>