Skip site navigation (1)Skip section navigation (2)
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>