IFQ_ENQUEUE argument refactor (was Re: RFC: ALTQ caller refactor)

[Joerg Sonnenberger]

I would suggest that the only "proper" use of mbuf tags as currently
implemented is experimentation. Uses of the tags which have been in
the tree for a decade or more should be subsumed into the mbuf
datastructure itself, with some care taken to not make it too large,
or perhaps a single, "standard" extension structure could be defined
to capture the less-common cases.

That's essentially what I said much earlier, except with packet header
instead of just mbuf.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

(Q2) How do I decide the data is too large or not?
e.g. ALTQ case, the data is struct altq_pktattr whose members are void *,
int, and void *.
http://nxr.netbsd.org/xref/src/sys/altq/if_altq.h#86
Is this three member struct too large?
another PACKET_TAG_PF m_tag case, the data is struct pf_mtag
http://nxr.netbsd.org/xref/src/sys/dist/pf/net/pf_mtag.h#46
How about this pattern?

Look at struct pkthdr. It's currently 2 pointers and 4 ints in the first
mbuf of every packet. We want to avoid pushing too much into it as the
rest of the mbuf is used for data, so "reasonable" small packets, we
want to completely stay in the first mbuf. The total size of a mbuf is
currently either 256 or 512 Bytes, mbuf header is < 60 Bytes, so
assuming that reasonable small means < 80 Bytes, we have around 120
Bytes or so to spend on the packet header.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

I implement moving struct altq_pktattr from m_tag to mbuf. Here is
the patch.
http://www.netbsd.org/~knakahara/mbuf-altq-pktattr/mbuf-altq-pktattr.patch

The only issue here is that I would prefer to not add the ALTQ
include, but just move the definition into sys/mbuf.h. Out of curiosity,
is the new size the same if you add the fields individually and the int
first? I.e. does using the struct add initial padding? It might be
useful at some point later to drop altq_pktattr as separate type
altogether and just use individual fields. As soon as some data after
pattr has to be added, we get padding on LP64 otherwise.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de