Date: Sun, 06 Oct 2002 23:09:27 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Sam Leffler <sam@errno.com> Cc: Nate Lawson <nate@root.org>, freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch Message-ID: <3DA12517.6D1B4EC2@mindspring.com> References: <Pine.BSF.4.21.0210062200110.5730-100000@root.org> <142f01c26dc1$6c4fa5b0$52557f42@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sam Leffler wrote: > > 1. Is ordering important or is an SLIST sufficient for all cases? > > Order is not important. Hm. I don't know if this is actually correct. I think if it went LIFO, you might not be very happy. I think it depends on what it's used for. > > 2. Is it possible to attach the aux argument to the mbuf chain instead of > > adding it as a new parameter to ip_output? > > The "aux argument" _was_ originally attached to the mbuf chain. The change > to add an extra arg to ip*_output was done to eliminate one of the biggest > uses of the aux mbuf; the socket to use to get IPsec policy. This is a > performance win and worth doing independent of the aux->m_tag switch. > > One could split the ip_output change out but doing it together avoids > converting code that would just eventually be eliminated (unless you did the > ip_output change first and then the m_tag switch). The IPSEC for IPv4 stuff is very ugly. It's tempting to say that it has nothing to do with the IP encapsulation, proper (conceptually, it should not). The big problem is that the IPSEC allocations are are there if IPSEC is compiled into the kernel at all, even if IPSEC is not being used on a particular socket. Actually, the integration into IPv4 strikes me as little more than an afterthought: the KAME code handles it in IPv6 without the extra overhead for the non-IPSEC sockets, and the IPv4 support is more of a bolt-on than something designed in. I'd almost want to see the IPSEC stuff treated as a separate encapsulation layer, on its own. Adding a aparameter for it specifically adds more cruft on the cruft that's already there, and makes the IPSEC *not* an encapsulation, in any way. 8-(. Is there another way to do this? A general extension mechanism for attributin mbufs seems to be a good idea. People have wanted this before, for credentials (e.g. Robert suggested something like this before). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DA12517.6D1B4EC2>