From owner-freebsd-net Wed Jun 19 13:56:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by hub.freebsd.org (Postfix) with ESMTP id 5807B37B407; Wed, 19 Jun 2002 13:56:45 -0700 (PDT) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.1/8.12.1) with ESMTP id g5JKugr4039189 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 19 Jun 2002 13:56:43 -0700 (PDT)?g (envelope-from sam@errno.com)œ Message-ID: <06bb01c217d3$d131b7f0$52557f42@errno.com> From: "Sam Leffler" To: "Luigi Rizzo" , "Julian Elischer" Cc: , References: <20020619094420.C58636@iguana.icir.org> <20020619122535.A60231@iguana.icir.org> Subject: Re: removing global variables from the network stack Date: Wed, 19 Jun 2002 13:56:42 -0700 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > 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