Date: Wed, 19 Jun 2002 13:56:42 -0700 From: "Sam Leffler" <sam@errno.com> To: "Luigi Rizzo" <rizzo@icir.org>, "Julian Elischer" <julian@elischer.org> Cc: <julian@FreeBSD.ORG>, <net@FreeBSD.ORG> Subject: Re: removing global variables from the network stack Message-ID: <06bb01c217d3$d131b7f0$52557f42@errno.com> References: <20020619094420.C58636@iguana.icir.org> <Pine.BSF.4.21.0206191148000.26167-100000@InterJet.elischer.org> <20020619122535.A60231@iguana.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> I agree with you (and Sam Leffler, who suggested a similar approach
> based on the m_tag as in NetBSD) as a long term solution (though I
> have some concerns on performance, as i mentioned in the dev.summit
> in february). However, proper handling of m_aux/m_tag chains (just
> look at Sam's patch) requires quite extensive changes, and I am
> afraid to break ipv6/kame stuff (which I have no way to test) in
> the process. I do not see this as a viable solution for RELENG_4.
>
FWIW my m_tag mods are based on openbsd code (which may well have come from
netbsd). Using m_tag actually simplifies the KAME code considerably since
there's no reuse of aux bufs (KAME plays some games with identifying what an
aux buf is used for based on it's size). I've been running IPV6 and IPSEC
"tortute tests" with these mods for 4+ months but they definitely need more
testing before committing anywhere (-stable or -current).
Also, as I said to you privately, m_tag support is required for the hardware
crypto mods I'm working on. They also are the mechanism by which NIC
drivers pass onboard processing state back up to the IPSEC code (i.e. crypto
results done on the NIC).
I'll think about how to add them to -stable w/o breaking binary
compatibility.
Sam
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?06bb01c217d3$d131b7f0$52557f42>