From owner-freebsd-arch Mon Oct 7 0:40:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB9A137B401; Mon, 7 Oct 2002 00:40:09 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72FD043EAA; Mon, 7 Oct 2002 00:40:09 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021007074008.OLCB18767.rwcrmhc53.attbi.com@InterJet.elischer.org>; Mon, 7 Oct 2002 07:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA32405; Mon, 7 Oct 2002 00:29:36 -0700 (PDT) Date: Mon, 7 Oct 2002 00:29:35 -0700 (PDT) From: Julian Elischer To: Sam Leffler Cc: Nate Lawson , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch In-Reply-To: <142f01c26dc1$6c4fa5b0$52557f42@errno.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 6 Oct 2002, Sam Leffler wrote: > > 1. Is ordering important or is an SLIST sufficient for all cases? > > Order is not important. I do similar in Netgraph but could move to whatever scheme becomes standard in the rest of the system. However I have some serious comments. In netgraph I have a separate structure for the packet that contains a pointer to the mbuf chain as well a pointer to a malloc'd memory buffer that can contain metadata such as is kept here. the metadata is of the form [header][field][field][field].... where each field was defined as: struct meta_field_header { u_long cookie; /* cookie for the field. Skip fields you don't * know about (same cookie as in messgaes) */ u_short type; /* field ID within this cookie scheme */ u_short len; /* total len of this field including extra * data */ char data[0]; /* data starts here */ }; the header for metadata is: struct ng_meta { char priority; /* -ve is less priority, 0 is default */ char discardability; /* higher is less valuable.. discard first */ u_short allocated_len; /* amount malloc'd */ u_short used_len; /* sum of all fields, options etc. */ u_short flags; /* see below.. generic flags */ struct meta_field_header options[0]; /* add as (if) needed */ }; /* Flags for meta-data */ #define NGMF_TEST 0x01 /* discard at the last moment before sending */ #define NGMF_TRACE 0x02 /* trace when handing this data to a node */ One metadata collection is associated with each packet. similar to what you do except that in 4.x Ipass it as an arguent and in 5.0 I have a packet header that is passed around that identifies both data and metadata. ( I need the header for other reasons anyway) I show this only to show that I have tackled the same problem with a similar but different scheme. My thought was that a packet usually only has at most a couple of tags, and the tags are usually short, so that it was ok to malloc a bigger chunk and using the length fields walk them. If you didn't have room you could malloc a bigger one and copy the intitial fields, and then add your new ones at the end. It would probably almost never happen.. I did however find a need to delete a tag once the packet passed out of the scope of the module in question. (the "cookie" represents a particular "ABI" the "type" is only valid withing the ABI. If you do not support a particular cookie type you cannot interpret the contents aof that field) Protocols and such have their own cookies. I point this out as a feature because the TAG values need to only be defined within their own ABI/API include files. If a module that supports a particular cookie passes a packet out to the rest of the world, it probably should invalidate some fields that are set with that particular cookie, in case that packet should in some way be redirected back towards a module that does support it, and that might cause unexpected results. For this reason I needed to 'remove' fields. I ended leaving them in place and setting the cookie to a special "invalid" cookie value that no-one would match. In a similar vein, I can imagine wanting to remove one of the 'tags' in your lists. Each module has a cookie field that is pretty much guaranteed to be unique (time since epoch when written) so in your terms, the IP code would only know and recognise TAGS prepended with the IP cookie and would handle other tags as opaque data. Similarly IPSEC code would only see into tags with the IPSEC cookie prepended.. I don't think you should be defining the TAG values in a global file, but rather each module should identify its own tags and ignode others. If two modules need to share data, a .h file can contain the defineitions for that API and the cookie that identifies such tags, and both modules would include that shared include. That way the base code need not know about future improvements, which has always been "difficult" :-) > > > 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). I'm not sure but it's possible m_aux was invented so that ip_output() would not change interfaces to match with was defined in some interface method table. I think NetBSD added entries in their interface method tables with varargs (yech) to get around some of this.. So in summary: is it worth making it a linked list? how many tags do you see on packets, and how large are they? CAn you use a sche,e suc as that outlined so that each module can define its own tags privatly? > > Sam > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message