From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
Date: Thu, 8 Mar 2007 23:16:58 -0800
> It seems expensive to change all the skb's if this type of
> event occurs,
The reset functions have to walk all the SKBs anyways.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> This is not a problem.
>
> Since the ->enqueue function stores references to the SKBs,
> any change of the dev->qdisc has to flush those references
> somehow, and it is at that point that you can fixup the skb
> queue mappings.
>
> This happens via invoking the qdisc->ops->reset() method.
>
From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
Date: Thu, 8 Mar 2007 22:42:19 -0800
> This was taken into consideration, and I did reply that my concern for
> doing that could cause stale data in the skb if the queue mapping
> changed.
This is not a problem.
Since the ->enqueue function stor
David Miller wrote:
You didn't address my correction the other day wherein I clarified
for you that my idea was not to store the queue mapping in
skb->priority but rather to shrink skb->priority to a u16 and
add a new u16 skb->queue_mapping or whatever field to store the
necessary information.
Y
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 08, 2007 10:22 PM
> To: Waskiewicz Jr, Peter P
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> Leech, Christopher
> Subject: Re: [PATCH 0/2] NET: Multiple
You didn't address my correction the other day wherein I clarified
for you that my idea was not to store the queue mapping in
skb->priority but rather to shrink skb->priority to a u16 and
add a new u16 skb->queue_mapping or whatever field to store the
necessary information.
You're just posting a
6 matches
Mail list logo
