Hello!
You're right. That makes it safe with preemption. However, netfilter
could still queue the packet which means the neigh entry and dev can
go away under it, right?
Netfilter is very clean about this. Each hook gets two devices as _arguments_
(input and output, skb-dev is one of them
On Tue, 2005-26-07 at 09:54 -0700, Ben Greear wrote:
[..]
You will need to enforce that nothing else gets the index 34 while eth7 is
removed.
How do you do that?
Thats trivial if you assume there's one management app which most of the
router vendors implementing it have. It will get tricky
On Tue, 2005-26-07 at 13:00 -0700, David S. Miller wrote:
Calling __dev_get_by_index() at every classification check is quite
silly and potentially expensive, so let's call using ifindex a last
resort, yet correct, fix.
Just double checking (I think we are saying the same thing),
that using
On Tue, 2005-26-07 at 21:54 +1000, Herbert Xu wrote:
David S. Miller [EMAIL PROTECTED] wrote:
But how can this possibly work for skb-dst'less packets (such as IPV4
ARP generated frames)?
I think the answer is that it works by accident.
But does it matter really? If say we close down
Hello!
But how can this possibly work for skb-dst'less packets (such as IPV4
ARP generated frames)?
Consider this as an implicit argument to functions passing skbs
(that's why skb-dev can be killed btw). Caller is obliged to hold
reference to the device, when doing dev_queue_xmit(). The way
On Tue, Jul 26, 2005 at 10:09:19AM -0400, jamal wrote:
I think the answer is that it works by accident.
But does it matter really? If say we close down the device,
do we want to be stopped from closing it until all the packets have been
transmitted? We purge the qdiscs iirc already on
On Sun, 2005-24-07 at 23:18 -0400, Jamal Hadi Salim wrote:
Posting a bunch of patches that explicitly set input_dev to dev
right before netif_rx() sort of further proves my point :-)
;-
Let me sleep it over and think about it - I am not thinking straight
right now. I am back home, so
From: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Mon, 25 Jul 2005 09:50:33 -0400
how about we set it in only ing_filter() if it is zero. i.e,
if (!skb-input_dev)
skb-input_dev = skb-dev-ifindex;
-
Ok... how about we take this one step further? The idea
being:
1)
From: Ben Greear [EMAIL PROTECTED]
Date: Sun, 24 Jul 2005 23:25:53 -0700
When these other changes go in, is there any chance that
we can get support for more than 256 routing tables? That
can help make all of these virtual interfaces more useful
for some of us with strange routing fetishes
From: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Mon, 25 Jul 2005 09:50:33 -0400
if (!skb-input_dev)
skb-input_dev = skb-dev-ifindex;
-
We get rid of the printk and all other places that set input_dev except
for mirred.
Any new actions can continue to set it if
From: Thomas Graf [EMAIL PROTECTED]
Date: Tue, 26 Jul 2005 00:35:05 +0200
We can also use ifindex and hold a reference. We won't access input_dev
too often so a __dev_get_by_ifindex() won't be too expensive given the
number of interfaces is not too big but that's another issue.
Since the
From: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Sat, 23 Jul 2005 09:32:07 -0400
This is part of mission skb diet.
Against git/davem/2.6.14 that was on vger 30 minutes back: It changes
input_dev to be an ifindex so we dont bother holding devices.
Would only cut a 4 byte fat on 64 bit
From: Thomas Graf [EMAIL PROTECTED]
Date: Sat, 23 Jul 2005 16:29:42 +0200
I think we should head for a 16bit ifindex at some point
or is there any reason why 65K interfaces wouldn't be
sufficient?
I think we are locked into using s32 for this.
I can definitely imagine virtual interfaces that
On Sun, 2005-24-07 at 19:02 -0700, David S. Miller wrote:
I agree they will mean the same thing.
The example i gave was to show where one meaning contradicts the other.
And the current specific settings of input_dev has the following
problems:
1) you cannot ingress classify on tunneling
* Jamal Hadi Salim [EMAIL PROTECTED] 2005-07-23 09:32
@@ -205,7 +205,6 @@ struct sk_buff {
struct sock *sk;
struct timeval stamp;
struct net_device *dev;
- struct net_device *input_dev;
struct net_device *real_dev;
On Sat, 2005-23-07 at 16:29 +0200, Thomas Graf wrote:
I think we should head for a 16bit ifindex at some point
or is there any reason why 65K interfaces wouldn't be
sufficient? We waste one bit at the moment to have simpler
error handling for all the functions returning indices.
Strange, i
* Jamal Hadi Salim [EMAIL PROTECTED] 2005-07-23 10:37
ifindex has to be 32 bit because most management apps (SNMP etc) expect
it to be 32 bit. I havent scanned the code but making int actually
doesnt seem right - unless some code is expecting it to be a -ve number
somewhere; it should be type
On Sat, 2005-23-07 at 16:50 +0200, Thomas Graf wrote:
No, we use s32 at the moment with the limitation that negative indices
are illegal. We don't have to break the interfaces just because of this,
but since dev_new_ifindex() will be reusing gone indices if needed it
might be possible to at
Jamal Hadi Salim wrote:
This is part of mission skb diet.
Against git/davem/2.6.14 that was on vger 30 minutes back: It changes
input_dev to be an ifindex so we dont bother holding devices.
Would only cut a 4 byte fat on 64 bit machines.
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
Jamal Hadi Salim wrote:
On Sat, 2005-23-07 at 16:50 +0200, Thomas Graf wrote:
No, we use s32 at the moment with the limitation that negative indices
are illegal. We don't have to break the interfaces just because of this,
but since dev_new_ifindex() will be reusing gone indices if needed it
Thomas Graf wrote:
I think we should head for a 16bit ifindex at some point
or is there any reason why 65K interfaces wouldn't be
sufficient? We waste one bit at the moment to have simpler
error handling for all the functions returning indices.
Although I don't know anyone doing so, it would
21 matches
Mail list logo
