Stephen Hemminger wrote:
On Wed, 08 Feb 2006 11:24:24 -0800
Ben Greear <[EMAIL PROTECTED]> wrote:
Stephen Hemminger wrote:
On Tue, 07 Feb 2006 16:26:01 -0800 (PST)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 7 Feb 2006 16:19:42 -0800
Also, isn't a lot of the problem reduced if network devices
are affinitied?
Not for routing/firewalling, we touch the destination device's
counters on input softing of the source device.
IMHO converting skb->dev to skb->devindex and using ifindex sounds best.
It gets rid of the need to refcount as much but keeps the safety from
buggy protocols. Ipv6 could probably use ifindex as well.
If we do this, can we keep a skb->dev pointer and assign it lazily
(sort of like we do with the timestamp?) That way, we can hopefully
optimize to not bump the refcount in the hot path, but older protocols
can easily be made to work as they have been...
No, just fix the protocols.
Well imagine that the protocol *does* need the netdev. If we have
to look it up once, might as well store the result in case the next
user of the skb also needs it. It's a net gain of 4 bytes in
the skb to preserve the skb pointer..seems like a reasonable tradeoff
to me.
Eventually, might be able to 'fix' all the protocols..but surely that
won't happen over-night.
If there is any ifidx -> skb lookups in the hot path, that is liable
to kill us since we'll have to take a lock and grovel through
the netdevice hash table?
The hash table locking could be per chain. or lockless.
Even a per chain lock would be worse than the atomic inc/dec
of the refcount, wouldn't it?
Now, a lockless table..that would be nice. That should be a win
regardless of any skb work. Sending packets to a packet-socket
uses a dev_get for every packet, for instance...
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
