On 28/6/17 2:31 am, Youssef GHORBAL wrote:
[...]
Further, I would argue that round robin is not a valid 802.3ad/802.1AX
algorithm, per how it defines a frame distributor:
"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.
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 the fact
that each flow needs to arrive on the same NIC and the system was designed with
this assumption in mind or not.
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 :
- 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 root cause
and help fixing it
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. But
it's not a behaviour to relay on. Right ?
Anyway, thank you very much for your help and the clarification on this issue.
Basically, while the packets are "on the wire" anything could happen.
It would be theoretically possible for a lagg interface to do packet
inspection and to not deliver (for some small amount of time) packets
which showed sign of a missing earlier packet, but this is the job of
other layers (e.g. tcp) and it would have negative impacts on
performance of otherwise well behaved flows as well.
It would have to actually look at tcp headers and that is WAY out of
scope for lagg. !t would also need a lot of state to be stored if it
were to hold state for all recent sessions, and make the code MUCH
more complicated.
Let tcp be tcp and push the linux owner to use something better.
Youssef
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
