Date: Mon, 27 Oct 2003 09:49:38 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: "Saye Balasubramaniam.S" <saye@cdotb.ernet.in> Cc: freebsd-arch@freebsd.org Subject: Re: Adding a new field into mbuf pkthdr structure Message-ID: <Pine.NEB.3.96L.1031027093414.99244B-100000@fledge.watson.org> In-Reply-To: <Pine.OSF.4.21.0310271514590.18837-100000@ws9.cdotb.ernet.in>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 27 Oct 2003, Saye Balasubramaniam.S wrote: > We are using FreeBsd stack in our new product. > I am planning to add a new field (integer)into the pkthdr struct > used in mbuf. I am worried about the side-effects of this. > Will there be any side-effects? Please give your > valuable feedback. The primary issue is binary compatibility, which may not be an issue at all for your product. By changing the size of struct mbuf, all kernel components using mbufs typically need to be recompiled, as the offset of data in an M_PKTHDR mbuf is located using the size of struct pkthdr. If you don't care about binary compatibility: i.e., you don't plan to use third party binary-only drivers, then this is not an issue. In our first pass at adding MAC labels to mbuf headers, we stored them directly in "struct pkthdr". The consequence was a slight reduction in the size of the data that could be held in an mbuf + M_PKTHDR without using a cluster. In practice this wasn't measurable in any normal benchmarks, although it you carefully sized test packets above and below that threshold size, it was noticeable. In addition, because "struct mac" is fairly large, you could measure an additional cost to zero the field even in systems without MAC enabled--again, fairly small, but measurable. The final problem we had to address in adding fields to the mbuf header was making sure that the value was properly managed when mbufs were copied. We found that, in earlier versions of FreeBSD, mbuf headers were relatively frequently allocated to hold copies of existing mbufs, but that the mbuf header fields (such as size, flags) were manually copied by calling code. In more recent versions of FreeBSD, header-copying and moving primitives, such as M_MOVE_PKTHDR() and m_dup_pkthdr() are used, which make it easier to maintain header values due to their central implementation. I would not be surprised if there are a couple of lurking places where packet header routines still need to be used to make sure that header entries are properly propagated, but most of them are handled. For example, I believe we may still need to modify the IP fragmentation code for outgoing packets to properly copy additional header fields and tags. One of the pieces of infrastructure introduced to support IPsec better was m_tags, a list of "tags" hung off of the mbuf header. This allows you to extend the contents of a header in a binary-compatible manner, although at a slight increase in cost in infrastructure due to additional memory allocation and pointer values. Tags are automatically maintained and copied over various mbuf operations, so you might want to give them a spin and see how the performance compares for your application. Hope this is helpful, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1031027093414.99244B-100000>