From: jamal <hadi@cyberus.ca>
To: Thomas Graf <tgraf@suug.ch>
Cc: Patrick McHardy <kaber@trash.net>,
netdev@vger.kernel.org, David Miller <davem@davemloft.net>
Subject: Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
Date: Fri, 30 Jun 2006 16:42:39 -0400 [thread overview]
Message-ID: <1151700159.5270.270.camel@jzny2> (raw)
In-Reply-To: <20060630200812.GM14627@postel.suug.ch>
On Fri, 2006-30-06 at 22:08 +0200, Thomas Graf wrote:
> * jamal <hadi@cyberus.ca> 2006-06-30 15:34
> > So assuming it is taken in mirred (i havent thought of where it is
> > decremented), why would using the ifindex be better?
>
> The issue exists regardless of mirred/ifb. As soon as the packet is
> queued for the first time we leave netif_receive_skb() and the dev
> reference is dropped. Therefore in order to allow functionality
> like tcf_match_indev() at egress we have to either take a reference
> or ensure that we can catch the unlikely case of the device having
> disappeared. I think everyone would agree to use device pointers
> if only mirred would acquire it.
Thomas, this is certainly more reasonable explanation.
On Fri, 2006-30-06 at 13:17 -0700, David Miller wrote:
> We have a
> lot of bits of state that sit in the sk_buff but which are used by
> a tiny minority, yet the space consumption is eaten by everyone.
>
>
> Maybe when the IFB and mirred are in more widespread use we can
> investigate a different approach.
>
Not unreasonable.
So saving the bits for the majority trumps the need for slightly more
cycles in mirred/ifb until they get more widespread.
> Another part of this issue is that if you use a pointer there is no
> clean place to clean up the input_dev reference within the scope it is
> actually used.
>
>
> The only reliable place is kfree_skb() which is far
> beyond the scope that this ->input_dev thing is used.
>
And i cant think of a good place to do it.
> We have a lot
> of problems in some parts of the networking because object references
> are held for too long. One example is all the awful side effects of
> the way the bridge netfilter code holds onto object references for
> long periods of time in the netfilter call chains.
>
> And we know the refcounting is broken. And one way we know to fix
> the refcounting without incurring the cost upon everyone is to
> use an interface index and only make the input_dev users eat the
> atomic operation incurred by grabbing the reference.
>
> And even for the input_dev users, it isn't such a big deal, there
> are other costs already associated with hitting these actions and
> devices that use input_dev, the atomic reference grab there should
> be lost in the noise I think.
Alright guys - lets get the change in. I wish we had this specific
discussion sooner.
Thomas, can you post your latest incarnation so i can mow comment more
peacefully? ;->
cheers,
jamal
next prev parent reply other threads:[~2006-06-30 20:42 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-26 14:54 [PATCHSET] Towards accurate incoming interface information Thomas Graf
2006-06-25 22:00 ` [PATCH 1/3] [NET]: Use interface index to keep input device information Thomas Graf
2006-06-25 22:00 ` [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device Thomas Graf
2006-06-26 17:04 ` Patrick McHardy
2006-06-26 17:46 ` David Miller
2006-06-26 18:24 ` Patrick McHardy
2006-06-26 18:44 ` Thomas Graf
2006-06-26 22:29 ` Patrick McHardy
2006-06-26 22:49 ` Patrick McHardy
2006-06-27 10:03 ` Thomas Graf
2006-06-27 13:07 ` jamal
2006-06-28 10:18 ` Thomas Graf
2006-06-28 12:22 ` jamal
2006-06-28 13:01 ` Thomas Graf
2006-06-28 13:46 ` jamal
2006-06-29 8:51 ` Thomas Graf
2006-06-29 20:55 ` Thomas Graf
2006-06-29 23:23 ` jamal
2006-06-29 23:39 ` Thomas Graf
2006-06-29 23:47 ` David Miller
2006-06-30 0:08 ` jamal
2006-06-30 0:12 ` David Miller
2006-06-30 0:26 ` jamal
2006-06-30 0:29 ` David Miller
2006-06-30 0:44 ` Ben Greear
2006-06-30 0:48 ` jamal
2006-06-30 0:55 ` Thomas Graf
2006-06-30 1:18 ` jamal
2006-06-30 0:03 ` jamal
2006-06-30 0:46 ` Thomas Graf
2006-06-30 1:11 ` jamal
2006-06-30 13:08 ` Thomas Graf
2006-06-30 13:20 ` Nicolas Dichtel
[not found] ` <44A52435.20909@6wind.com>
2006-06-30 13:36 ` Thomas Graf
2006-06-30 13:43 ` Nicolas Dichtel
2006-06-30 17:01 ` Patrick McHardy
2006-06-30 17:02 ` Patrick McHardy
2006-06-30 13:57 ` jamal
2006-06-30 14:15 ` Thomas Graf
2006-06-30 14:35 ` jamal
2006-06-30 15:40 ` Ben Greear
2006-06-30 16:32 ` Thomas Graf
2006-06-30 17:13 ` Thomas Graf
2006-06-30 17:18 ` Patrick McHardy
2006-06-30 17:32 ` jamal
2006-06-30 17:42 ` Patrick McHardy
2006-06-30 17:44 ` Thomas Graf
2006-06-30 19:40 ` jamal
2006-06-30 20:17 ` David Miller
2006-06-30 17:42 ` Thomas Graf
2006-06-30 19:34 ` jamal
2006-06-30 20:08 ` Thomas Graf
2006-06-30 20:42 ` jamal [this message]
2006-06-30 17:27 ` Ben Greear
2006-06-30 21:09 ` jamal
2006-06-30 21:20 ` Thomas Graf
2006-06-30 21:35 ` jamal
2006-06-30 23:22 ` Thomas Graf
2006-07-01 2:23 ` jamal
2006-07-01 11:51 ` Thomas Graf
2006-07-01 13:47 ` jamal
2006-06-30 17:19 ` jamal
2006-06-30 17:33 ` Patrick McHardy
2006-06-30 19:59 ` jamal
2006-06-30 20:30 ` Thomas Graf
2006-06-30 20:33 ` David Miller
2006-06-30 20:54 ` jamal
2006-06-30 21:10 ` Thomas Graf
2006-06-30 21:31 ` jamal
2006-06-30 23:45 ` Thomas Graf
2006-07-01 2:59 ` jamal
2006-07-01 11:28 ` Thomas Graf
2006-07-01 13:35 ` jamal
2006-07-08 10:54 ` Thomas Graf
2006-07-08 14:14 ` Jamal Hadi Salim
2006-07-08 14:29 ` Jamal Hadi Salim
2006-07-08 23:46 ` Thomas Graf
2006-07-08 23:48 ` Thomas Graf
2006-07-09 12:52 ` Jamal Hadi Salim
2006-07-09 13:17 ` Jamal Hadi Salim
2006-07-09 13:33 ` Thomas Graf
2006-07-09 14:03 ` Jamal Hadi Salim
2006-07-09 14:19 ` Thomas Graf
2006-07-09 15:00 ` Jamal Hadi Salim
2006-07-09 15:54 ` Thomas Graf
2006-07-09 23:06 ` Jamal Hadi Salim
2006-07-01 2:47 ` Patrick McHardy
2006-06-30 17:34 ` Thomas Graf
2006-06-25 22:00 ` [PATCH 3/3] [PKT_SCHED]: Add iif meta match Thomas Graf
2006-06-27 15:07 ` [PATCHSET] Towards accurate incoming interface information Thomas Graf
2006-06-27 20:24 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1151700159.5270.270.camel@jzny2 \
--to=hadi@cyberus.ca \
--cc=davem@davemloft.net \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=tgraf@suug.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).