Date: Fri, 09 Feb 2001 17:43:15 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Alex Pilosov <alex@pilosoft.com> Cc: Chris Dillon <cdillon@wolves.k12.mo.us>, Dan Nelson <dnelson@emsphone.com>, Bill Paul <wpaul@FreeBSD.ORG>, hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: call for testers: port aggregation netgraph module Message-ID: <200102092243.f19MhFC11639@whizzo.transsys.com> In-Reply-To: Your message of "Fri, 09 Feb 2001 17:23:02 EST." <Pine.BSO.4.10.10102091721400.31680-100000@spider.pilosoft.com> References: <Pine.BSO.4.10.10102091721400.31680-100000@spider.pilosoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The crock in these trunking schemes is all the trouble and effort expended to avoid re-ordering frames across the trunk bundle. This is why you see things like the hashing techniques so that an individual flow of traffic doesn't get reordered because it always is serialized over the a single path. I'll observe that there's nothing in the IP architecture which (should) rely on packets not being reordered. I'll also observe that in a network with multiple ethernet switching running a spanning-tree protocol, you probably should't rely on packet reordering never happening when a link fails and the spanning tree computation is re-run. So, a clever implementation might choose to drain a single queue rather than having multiple queues, one per network interface. Of course, some network stacks don't deal well with TCP segments arriving out-of-order, but they are just broken. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102092243.f19MhFC11639>