Re: [PATCH] skbuff: Add new tc classify variable

[Eric Dumazet <eric.dumazet@xxxxxxxxx>]

Le mardi 07 février 2012 à 21:16 +0100, Simon Wunderlich a écrit :
> Hello David,
> 
> On Tue, Feb 07, 2012 at 01:58:41PM -0500, David Miller wrote:
> > From: Simon Wunderlich <simon.wunderlich@xxxxxxxxxxxxxxxxxxxx>
> > Date: Tue,  7 Feb 2012 19:39:08 +0100
> > 
> > > The linux traffic control mechanism has different ways to select the
> > > correct class of a qdisc. A common way to do this is to use tc filters
> > > that are directly attached to a qdisc. Another approach is to use the
> > > iptables classify module. The latter one can reduce the amount of work
> > > necessary to process a packet when iptables is already involved in the
> > > packet classification.
> > 
> > Do not bloat up sk_buff any more.  Add this, and the other existing
> > tc_* members to the qdisc SKB control block instead.
> > 
> 
> Thanks for your feedback!
> 
> I guess you mean skb->cb, but this is also used within mac80211 for various things
> (quoting include/net/mac80211.h):
> 
>  * struct ieee80211_tx_info - skb transmit information
>  *
>  * This structure is placed in skb->cb for three uses:
>  *  (1) mac80211 TX control - mac80211 tells the driver what to do
>  *  (2) driver internal use (if applicable)
>  *  (3) TX status information - driver tells mac80211 what happened
> 
> We could give it a try, but we most probably run into conflicts again.
> 
> I've messed up the CCs in my initial mail (and just resent it) - sorry about that.
> Maybe the mac80211 guys have a suggestion as well :)
> 

I really dont understand what the conflict might be.

As long as skb is in Qdisc layer, Qdisc owns skb->cb[] (a part of it
actually, see current discussions about IB on netdev)

As soon as packet is given to device (mac80211), cb[] can be reused.

Or are you saying tc_class also might be needed by mac80211 in the
future ?



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html