Date: Sat, 20 Aug 2016 17:57:26 +0100 From: Bruce Simpson <bms@fastmail.net> To: Ryan Stone <rysto32@gmail.com> Cc: Ryan Stone <rstone@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Adrian Chadd <adrian@freebsd.org> Subject: Re: svn commit: r304436 - in head: . sys/netinet Message-ID: <7779ae65-5366-0f42-4369-7f0647abca3c@fastmail.net> In-Reply-To: <990e003f-6180-b016-3b5f-6bdf579d073f@fastmail.net> References: <201608182259.u7IMx5oW002018@repo.freebsd.org> <4fbc2e1d-3a62-5963-83d5-f9c931503e51@fastmail.net> <3806700d-ed27-7915-4818-c2d64f7b806d@fastmail.net> <CAFMmRNyi=PwE9pc9_8wCU63=HttUzFR4Zh2v=uHKcQ-zaLxdJQ@mail.gmail.com> <fcb33eac-ec99-03c7-57b5-f24f86c4f41a@fastmail.net> <CAFMmRNwDPy4Hd35DrfREZQzjvd89qw=zhEriddG8U8NV7tD=EA@mail.gmail.com> <6f4449f2-d145-8b49-c3f0-433e8ff4d2a2@fastmail.net> <CAFMmRNypgJc00XH277oB3EEGje4xq%2B8_qcJfZu4jjBfTfa7GGQ@mail.gmail.com> <990e003f-6180-b016-3b5f-6bdf579d073f@fastmail.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20/08/16 17:49, Bruce Simpson wrote: >> - Providing a mechanism for ip_input() to signal to udp_input() that the >> packet was addressed to an L3 broadcast address would require >> rototilling the pr_input interface, and I'd have to carefully ensure >> that if anything might interpose itself between the two layers (IPSec?) >> that the flag would have to be passed through correctly. > (We had to do something similar for ILNPv6, because of how IPv6 input > works, so it allocates an unused bit from the IPv6 flow label.) In case anyone's interested, IPSEC is one big reason we had to do this. Performance was another; without marking ILNPv6 traffic, demultiplexing an ILNPv6 packet -- even 'just enough' to forward it -- would have required processing all IPv6 extension headers, and additional state lookups. Using a bit from the flow label means ILNPv6 routers don't need to do any of that, and it got translated into an M_ILNP mbuf flag internally. I shudder to think what gymnastics the FreeBSD stack may have to endure to accommodate modern Ethernet switching capabilities, though.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7779ae65-5366-0f42-4369-7f0647abca3c>