Do we really need an 'unsigned int' for mac_len? Maybe we could use
a 16-bit counter here, and then use the other 16 bits for the VLAN bits?
Not knowing exactly if/how it interacts with that specific field I will
point-out that IPoIB in OFED 1.2 just took their MTU to 65520. While that
Do we really need an 'unsigned int' for mac_len? Maybe we could use
a 16-bit counter here, and then use the other 16 bits for the VLAN bits?
Not knowing exactly if/how it interacts with that specific field I
will point-out that IPoIB in OFED 1.2 just took their MTU to 65520.
While
I was going to forget this, but its been playing in the back of my head
and wont go away
Matt Carlson recently (while fixing the tg3 driver in my batching
patches) pointed to me that skb-cb[] was being used to pass around vlan
data.
This seems like a bad use since there can be a lot of
From: jamal [EMAIL PROTECTED]
Date: Mon, 30 Jul 2007 20:59:16 -0400
This seems like a bad use since there can be a lot of things between
a real hardware driver and something that sets a vlan tag (qdiscs come
to mind).
I understand the concern, but how much qdisc stuff can possibly
happen
On Mon, 2007-30-07 at 18:33 -0700, David Miller wrote:
I understand the concern, but how much qdisc stuff can possibly
happen between those two -hard_start_xmit() calls and do we
want to support that in any way anyways?
From a quick glance only netem seems to use it in the fast path (in a
From: jamal [EMAIL PROTECTED]
Date: Mon, 30 Jul 2007 22:02:04 -0400
I came across the issue because i used cb in batching to store transient
state which is used between qdisc dequeueing and hardware enqueueing
(looked and smelled legit to me).
Right, dequeue-device should be OK and doesn't
David Miller wrote:
From: jamal [EMAIL PROTECTED]
Date: Mon, 30 Jul 2007 22:02:04 -0400
I came across the issue because i used cb in batching to store transient
state which is used between qdisc dequeueing and hardware enqueueing
(looked and smelled legit to me).
Right,
From: Ben Greear [EMAIL PROTECTED]
Date: Mon, 30 Jul 2007 21:30:19 -0700
So, shall we add a new field to the skb in order to get the info out of cb?
Looks like a single 32-bit field would be sufficient.
I'm trying to brainstorm how to avoid consuming new space in
sk_buff and I'd like others
David Miller wrote:
From: Ben Greear [EMAIL PROTECTED]
Date: Mon, 30 Jul 2007 21:30:19 -0700
So, shall we add a new field to the skb in order to get the info out of cb?
Looks like a single 32-bit field would be sufficient.
I'm trying to brainstorm how to avoid consuming new space in
