Date: Tue, 27 Jun 2017 18:31:04 +0000 From: "Youssef GHORBAL" <youssef.ghorbal@pasteur.fr> To: Matt Joras <matt.joras@gmail.com> Cc: "sthaug@nethelp.no" <sthaug@nethelp.no>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, "nparhar@gmail.com" <nparhar@gmail.com> Subject: Re: Sporadic TCP/RST sent to client Message-ID: <FBF1C913-462F-4C10-B517-EDDCA8247B4A@pasteur.fr> In-Reply-To: <CADdTf%2Bj45ThMi3j-v2ocEAY7w4PnBhakNEBmATi8dTe4_CQksg@mail.gmail.com> References: <CAPFoGT8sthFOm=vOiFb9%2B2BM=%2BBqtREz1SrOm_UiVge81CrYrw@mail.gmail.com> <CADdTf%2BgeCy4naC5jJ6UhTm7-n9c6XKpgRs96EsXGq-UVjSn8MQ@mail.gmail.com> <5ABA962E-A90A-4C25-A5A7-EE5CF66FFDD4@pasteur.fr> <20170627.125426.74697078.sthaug@nethelp.no> <CB4FA7F4-6DAC-4231-8CE1-AB83525F0F23@pasteur.fr> <CADdTf%2Bj45ThMi3j-v2ocEAY7w4PnBhakNEBmATi8dTe4_CQksg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[...] > Further, I would argue that round robin is not a valid 802.3ad/802.1AX > algorithm, per how it defines a frame distributor: >=20 > "This standard does not mandate any particular distribution > algorithm(s); however, any distribution algorithm shall ensure that, > when frames are received by a Frame Collector as specified in 5.2.3, > the algorithm shall not cause: > a) Misordering of frames that are part of any given conversation, or > b) Duplication of frames. >=20 > The above requirement to maintain frame ordering is met by ensuring > that all frames that compose a given conversation are transmitted on a > single link in the order that they are generated by the MAC Client; > hence, this requirement does not involve the addition (or > modification) of any information to the MAC frame, nor any buffering > or processing on the part of the corresponding Frame Collector in > order to reorder frames." I tend to agree with you on this point. >> Sure, I was just wondering if the FreeBSD network stack was built with t= he fact that each flow needs to arrive on the same NIC and the system was d= esigned with this assumption in mind or not. >>=20 >> I reported it here, thinking that maybe it's a subtle buggy corner case = and maybe the community was interesting to know about and maybe fix : >>=20 >> - If the stack is working as expected and was built with the assumption = that each incoming flow needs to stick to a NIC during it's lifetime, maybe= documentation needs to be more explicit regarding this situation. In that = case I'll file documentation enhancement bug report. >> - If the stack is misbehaving, maybe help the community identify the roo= t cause and help fixing it >>=20 > As far as I can tell, as Navdeep noted, there's no unexpected > behaviour in your case. "Flows" are a concept that the protocols, in > this case TCP, knows about. The devices themselves (Ethernet cards) > usually have mechanics to make packet delivery decisions based on flow > information (e.g. RSS hashing), but as far as I know that is generally > limited within a single port, so it doesn't really help in the general > case of a lagg. So the fact that it works most of the time is just a "happy" coincidence. B= ut it's not a behaviour to relay on. Right ? Anyway, thank you very much for your help and the clarification on this iss= ue. Youssef=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FBF1C913-462F-4C10-B517-EDDCA8247B4A>