On Sun, 30 Jul 2006, Sam Leffler wrote:
I'm a little uncomfortable with our current m_tag model, as it requires
significant numbers of additional allocations and frees for each packet, as
well as walking link lists. It's fine for occasional discretionary use
(i.e., MAC labels), but I worry about cases where it is used with every
packet, and we start seeing moderately non-zero numbers of tags on every
packet. I think I would be more comfortable with an explicit queue
identifier argument to if_start, where the link layer and driver layer
agree on how to identify queues.
As a straw man, how would the following strike you:
int if_startmbuf(struct ifnet *ifp, struct mbuf *m, int ifqid);
where for most link layers, the value would be zero, but for some link
layer/driver combinations, it would identify a specific queue which the
link layer believes the mbuf should be assigned, if implemented?
mbuf tags are not a solution; too expensive. I think we need something in
the mbuf header.
Agreed. I'm also quite unhappy that we have to use m_tags for VLAN tagging
for identical reasons: it basically guarantees at least one extra memory
allocation and free, possibly two, for each frame with encapsulation. This is
one of the reasons I have been interested in reworking the ethernet link layer
parts to increase integration of VLANs into the normal ethernet code, in order
to avoid having to unnecessarily use expensive mbuf meta-data.
What size field is needed in the mbuf pkthdr to capture all the necessary
priority information between driver and link layer? An int?
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
