Re: Changes in the network interface queueing handoff model


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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Changes in the network interface queueing handoff model
    ... significant numbers of additional allocations and frees for each packet, as well as walking link lists. ... It's fine for occasional discretionary use, 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. ... the mbuf header. ...
    (freebsd-arch)
  • Re: broadcast to internet?
    ... >> IP applications should never see the link layer source address ... >> layer destination address on the network in question. ... > several applications ... The packet doesn't get to the application ...
    (comp.security.firewalls)
  • Re: VXWORKS 6.0 :From vxworks sending a layer2 packet ( USING ONLY MAC ADDRESS )
    ... X86 machine loaded with vxworks image. ... AXEL_X network processor code is included into my vxworks image. ... I have my linux x86 OS from which I am sending a packet using ... Vxworks 6.x doesn't support sockaddr_ll structure and link layer ...
    (comp.os.vxworks)
  • Re: broadcast to internet?
    ... > applications interpret the local link layer broadcast address, ... fits into 32 bits in the destination address field in the IP header ... IP applications should never see the link layer source address ... One can have a packet which is broadcast on the link layer but which ...
    (comp.security.firewalls)