From: jamal <hadi@cyberus.ca>
To: Thomas Graf <tgraf@suug.ch>
Cc: Patrick McHardy <kaber@trash.net>,
David Miller <davem@davemloft.net>,
netdev@vger.kernel.org
Subject: Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
Date: Sat, 01 Jul 2006 09:47:19 -0400 [thread overview]
Message-ID: <1151761639.5093.154.camel@jzny2> (raw)
In-Reply-To: <20060701115112.GT14627@postel.suug.ch>
On Sat, 2006-01-07 at 13:51 +0200, Thomas Graf wrote:
> * jamal <hadi@cyberus.ca> 2006-06-30 22:23
> > I am not certain i understood then: Are we in the mode where the
> > refcount is not needed because chances are small that a device will
> > disappear? It seems to me after all this trouble that it may not be so
> > bad to refcount (I guess i meant refcount the device on input to the ifb
> > and decrement on the output).
>
> Based on two principles:
>
> a) All netdevices a packet is processed through is properly
> refcounted until the packet is queued for the first time.
> Given that iif is strictly set to the previous device, a
> refcnt is certainly taken up to the point where the skb is
> put into rq.
yes, but that refcount may be lost by the time it is dequeued and
retransmitted. Am i wrong thinking so?
> There is one exception to this: The fact that
> you don't set skb->dev = ifb when reinjecting at ingress
> will not take a refcnt on the ifb. This sounds like a broken
> architecture to me but it doesn't matter as you want to
> prohibit ifb -> ifb anyways.
Ok, Thomas: Please stop critiqueing the architecture non-stop. You will
not convince me of anything this way. Lets just focus on this issue and
then you can go back and critique all you want.
>
> b) The netdevice used for xmit via dev_queue_xmit() is already
> protected by the initial xmit attempt.
>
Is it guaranteed? if yes, the patch is perfect.
> I can't see reason why to hurt performance by introducing more
> atomic operations in your fast path.
>
well, i would be fine with this - with a caveat that nothing really has
changed in ifb then, no? i.e the value of the patch in that case would
be to convert input_dev to iif, correct? If yes, this is fine by me
since as we have discussed the likelihood of this was small.
> If you have more concerns regarding these patches, feel free to
> fix your own architecture or propose to drop the patches, I think
> I've spend enough time on this.
Again, you are not being helpful by throwing in side remarks like these.
I am being very fair to you when you ask questions on how X works after
all assumptions you make - yet i ask questions which i see as valid and
you start throwing your hands off in the air. And then Patrick says i am
creating endless debates; this is why we go into loops.
Just answer the questions: I am trying to understand or you can choose
to ignore the emails all together.
cheers,
jamal
next prev parent reply other threads:[~2006-07-01 13:47 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
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
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 [this message]
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
[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-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=1151761639.5093.154.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).