From: Ben Greear <greearb@candelatech.com>
To: Tommy Christensen <tommy.christensen@tpack.net>
Cc: "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>,
"Linux 802.1Q VLAN" <vlan@candelatech.com>,
Francois Romieu <romieu@fr.zoreil.com>,
"David S. Miller" <davem@redhat.com>
Subject: Re: [PATCH] 802.1Q VLAN
Date: Fri, 29 Oct 2004 16:56:17 -0700 [thread overview]
Message-ID: <4182D8A1.1070801@candelatech.com> (raw)
In-Reply-To: <4182D44E.7070507@tpack.net>
Tommy Christensen wrote:
> Ben Greear wrote:
>
>> You can't send shared skbs regardless, because the vlan Xmit changes
>> the skb->dev at least, so
>> you just have to set the multi-skb setting in pktgen to 0 so that it
>> does not
>> share when using VLANs.
>
>
> By sheer accident, this would actually work! Nevertheless, the code
> should obviously handle this correctly (whatever that means?!).
It definately crashed on my system when I tried it, so I don't think
it actually works. Think about a SMP system where pktgen is re-sending
the same pkt while the other CPU is handling the previous send..or something
like that. The fact that skb->dev is changing cannot be healthy.
From what I can tell, a net-devices hard_start_xmit method must either
return 0 and consume the skb, or return a non-zero value and not
consume the skb. Since we can detect immediate drops due to the
dev_queue_xmit call failing, I don't see how it can hurt anything to
preserve the skb and return the error code. Code that cares about retransmitting
can, and if it doesn't, it can just delete the skb.
I believe this is the same as the case where the e1000 does not
show netif_queue_stopped() but still returns failure when you
try the hard_start_xmit. I know that this case will probably
eventually be fixed, but the fact that it *does* work leads me to
believe I can get away with what I'm trying to do with VLANs.
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2004-10-29 23:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-22 21:07 [PATCH] 802.1Q VLAN Ben Greear
2004-10-22 21:46 ` Francois Romieu
2004-10-22 22:09 ` Ben Greear
2004-10-23 0:24 ` Francois Romieu
2004-10-25 20:51 ` Ben Greear
2004-10-25 23:56 ` Ben Greear
2004-10-27 1:02 ` David S. Miller
2004-10-27 23:49 ` David S. Miller
2004-10-28 1:28 ` Ben Greear
2004-10-28 4:42 ` David S. Miller
2004-10-28 23:40 ` Tommy Christensen
2004-10-28 23:35 ` David S. Miller
2004-10-29 0:23 ` Ben Greear
2004-10-29 0:38 ` Krzysztof Halasa
2004-10-29 8:29 ` Tommy Christensen
2004-10-29 17:45 ` Ben Greear
2004-10-29 23:37 ` Tommy Christensen
2004-10-29 23:56 ` Ben Greear [this message]
2004-10-30 0:05 ` Ben Greear
2004-10-30 0:31 ` Tommy Christensen
2004-11-01 18:58 ` Ben Greear
2004-11-01 23:08 ` Tommy Christensen
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=4182D8A1.1070801@candelatech.com \
--to=greearb@candelatech.com \
--cc=davem@redhat.com \
--cc=netdev@oss.sgi.com \
--cc=romieu@fr.zoreil.com \
--cc=tommy.christensen@tpack.net \
--cc=vlan@candelatech.com \
/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).