Date: Mon, 07 Oct 2002 15:35:08 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Sam Leffler <sam@errno.com>, freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: CFR: m_tag patch Message-ID: <3DA20C1C.A4B863B7@mindspring.com> References: <Pine.BSF.4.21.0210071322090.34884-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > Firstlty, each netgraph module type is ignorant of > all other types (except in some special cases). Each 'type' > labels its structures, control messages, and in fact special metadata > that it keeps on a packet, using a special maginc number. Each 'type' > of netgraph node (e.g. ppp node, or frame-relay-mux node) > defines a different 32 bit magic number (traditionally in netgraph > it's just the 32 bit time since the epoch when the module was written). I think the biggest problem is that mbuf lists are not the same thing as packets, and they may not even contain *whole* packets, depending on where in the process you are examining them. Therefore the idea of "packet attributes" is broken to begin with -- particularly, since if the attribute results in TCP options being set on all frags for the packet in question, you will change the amount of real data being sent in the frag. If you are going to treat it as an attribute, then the abstract thing you need to be passing around is a packet, not an mbuf chain. This is probably not a good idea, in general, even if it would let you do nifty things. One obvious application here is to communicate flow information from a front end router to a back end server and/or load balancer, in order to permit it to make better decisions. Such information would be tunnelled in option data on the payload packets between the router and the other end. > Your tags have a single 16 bit tag ID field. > This is insufficient for my needs. > I need to be able to store the API cookie which is a 32 bit > unsigned number, and on top of that, I also need a 16 bit type field > that specifies what the data is within teh given API and a 16 bit > length to allow opaque handling. This is insufficient for Alpha and other 64 bit architectures. I think what you are asking for is really a 'void *'. The other issue here is that your idea of an opaque API/ABI indicator is in conflict, unless you say that this is a pointer, and then format the initial information pointed to by the pointer. Otherwise, you will need a small indirection structure that's pointed to the pointer, AND which contains the API/ABI identifier (i.e. you will need two, not one piece of information for that -- which is what you show, but not what you describe in your text). [ ... ] > If you allocated your API definitions corectly > using my scheme, you might allocate a API number of > 1034025045 for example to the IPSEC-CRYPTO interface. > and that API would define it's own IDS for metadata. > This would not be able to accidentally match with the Priority > metadata used for frame relay (if you sent Ipsec over frame relay) > because (for example) teh frame relay API number is 872148478 > /usr/include/netgraph/ng_frame_relay.h line 48 > > #define NGM_FRAMERELAY_COOKIE 872148478 This is moderately bogus. Specifically, ig you are going to register in new types without an assigned numbers authority (e.g. if I have a vendor private extension, which I wish to implement, yet not have collide with someone else's vendor private extension or a future FreeBSD "standard extension"), then you need to implement a registration interface for named registration, and use *that*. The easiest way to do this would be to ensure that you use the *runtime* kernel address as your identifier, which guarantees that it will be unique in any given system. Yes, I realize that this means that a switch statement may not be used internally to dispatch. In theory, this metadata is an exceptional condition, rather than a common condition (otherwise, the overhead becomes prohibitive, I think, and you might as well put it inline). I think the value of a unique identifier is more important than the ability to switch. If it comes down to it, something which does not conflict is more useful than something which would be faster if it didn't conflict, but doesn't run at all because it doesn't get the chance. > You wouldn't have to know about frame relay and frame relay doesn't need > to know about IPSEC, but it does know how to free the metadata if it > needs to discard the packet. Yes. This implies that metadata ownership indicates a permetadata destructor type; for example, a reference to an object that will no longer be referenced, should the packet be discarded. > As I mentionned before, it is also not clear to me that the metadata > needs to be in linked list form, but I could live with it. I think it has to. The reason he has this is pretty clear from his crypto work, and the reason for the linked list is to, in the limit, allow a linear traversal of the list elements to find data that's relevent to you. It's kind of ugly, but "anything that works is better than anything that doesn't"... it at least guarantees that it *can* work. -- Terry 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?3DA20C1C.A4B863B7>