[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+FuTScV8AgEumMsPnVVmRkYKjbJYLigAqqhrgzx9DDsXDz=2w@mail.gmail.com>
Date: Wed, 25 Feb 2015 15:49:40 -0500
From: Willem de Bruijn <willemb@...gle.com>
To: Eyal Birger <eyal.birger@...il.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
David Miller <davem@...emloft.net>,
Shmulik Ladkani <shmulik.ladkani@...il.com>,
Eric Dumazet <edumazet@...gle.com>,
Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v3 3/4] net: use skb->priority for overloading
skb->dropcount and skb->reserved_tailroom instead of skb->mark
>> We have to be a bit creative/hacky to keep skb size small.
>>
>
> I agree. I don't think these feature deserve an skb size increase, so
> some hackery is required.
>
> Though, as skb->cb[] is somewhat 'owned' by the protocol families on
> socket enqueue
> I tend to find aliasing skb->priority with skb->dropcount "a lesser
> evil" as compared with
> partitioning the skb->cb[] space.
Please consider another field than priority. There are use
cases that want to receive priority, similar to reading mark.
Indeed, I have a draft packet auxdata patch for one user who wants
to see the iptables changes (and infer tc effects) on egress packets.
Fwiw, that patch also exposes mark, and runs into exactly this issue
that you're fixing, so thanks :)
Fields that are consistently NULL on enqueue, such as the dev field
that Eric proposed, do not have this drawback.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists