Date: Thu, 4 Jan 2018 14:42:14 -0800 From: hiren panchasara <hiren@strugglingcoder.info> To: Steven Hartland <steven@multiplay.co.uk> Cc: Eugene Grosbein <eugen@grosbein.net>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r327559 - in head: . sys/net Message-ID: <20180104224214.GD18879@strugglingcoder.info> In-Reply-To: <f133b587-1f7e-4594-31d1-974775ad55be@freebsd.org> References: <201801042005.w04K5liB049411@repo.freebsd.org> <5A4E9397.9000308@grosbein.net> <f133b587-1f7e-4594-31d1-974775ad55be@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--zaRBsRFn0XYhEU69 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 01/04/18 at 09:52P, Steven Hartland wrote: > On 04/01/2018 20:50, Eugene Grosbein wrote: > > 05.01.2018 3:05, Steven Hartland wrote: > > > >> Author: smh > >> Date: Thu Jan 4 20:05:47 2018 > >> New Revision: 327559 > >> URL: https://svnweb.freebsd.org/changeset/base/327559 > >> > >> Log: > >> Disabled the use of flowid for lagg by default > >> =20 > >> Disabled the use of RSS hash from the network card aka flowid for > >> lagg(4) interfaces by default as it's currently incompatible with > >> the lacp and loadbalance protocols. > >> =20 > >> The incompatibility is due to the fact that the flowid isn't know > >> for the first packet of a new outbound stream which can result in > >> the hash calculation method changing and hence a stream being > >> incorrectly split across multiple interfaces during normal > >> operation. > >> =20 > >> This can be re-enabled by setting the following in loader.conf: > >> net.link.lagg.default_use_flowid=3D"1" > >> =20 > >> Discussed with: kmacy > >> Sponsored by: Multiplay > > RSS by definition has meaning to received stream. What is "outbound" st= ream > > in this context, why can the hash calculatiom method change and what ex= actly > > does it mean "a stream being incorrectly split"? > Yes RSS is indeed a received stream but that is used by lagg for lacp=20 > and loadbalance protocols to decide which port of the lagg to "send" the= =20 > packet out of. As the flowid is not known when a new "output" stream is= =20 > instigated the current code falls back to manual hash calculation to=20 > determine which port to send the initial packet from. Once a response is= =20 > received a tx then uses the flowid. This change of hash calculation=20 > method can result in the initial packet being sent from a different port= =20 > than the rest of the stream; this is what I meant by "incorrectly split". For my understanding, is this just an issue for the first packet when we originate the flow? Once we have a response and if flowid is there, we'd use it, right? OR am I missing something?=20 And with this change, we'd always go and do manual calculation even when we have a valid flowid (i.e. we didn't initiate a connection)? Thanks, Hiren >=20 > See the following: > https://github.com/freebsd/freebsd/blob/master/sys/net/if_lagg.c#L2066 > https://github.com/freebsd/freebsd/blob/master/sys/net/ieee8023ad_lacp.c#= L846 >=20 > > Defaults should not be changed so easily just because they are not opti= mal > > for some specific case. Each lagg has its own setting for flowid usage > > and why one cannot just use "ifconfig lagg0 -use_flowid" for such cases? > > > Yes we're already using -use_flowid to mitigate the problem, but the=20 > defaults should never result in broken behavior hence the change, at=20 > least for now. >=20 > For reference I did look at keeping the default of 1 but only using that= =20 > for protocols which weren't effected by the issue, and introducing a 2=20 > to force those that are, but as its defined as acting on creation and we= =20 > always create lagg interfaces as failover and then amend them that=20 > wasn't possible without making more invasive changes. >=20 > ??? Regards > ??? Steve --zaRBsRFn0XYhEU69 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJaTq3DXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lO7IIAIttys/MHCicyyy/Ioi6f9Xa tWlZldwa/x4pR6pjt+/k79edyjagzDWPnNUlPL449iY8HIqk62/y3AEZasge5SGs XlIn9I3zadhMXDOp4zDmv2MIFbQJEEc2FmkqOziddFZP1rrLFIQhivlE5wvoGQkj MIQCzwByT/QlKbDCXt5PiMwk6OTzxbU/oMHCcIAN/uHomfiafZ+iWOFsjnGqm0MH NGG8u8os9Cl5IlvYfENod7RSi1abkkAjrBtTlvF+Ke6dycP37lOnNPy7ALvatFlb LSoQzfE+YDAsoCOyS5i8j581sQLuJZKCX4OVVrYVL0+j/Tjq2KNXZop5BQ8beqY= =Irfa -----END PGP SIGNATURE----- --zaRBsRFn0XYhEU69--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180104224214.GD18879>