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 17:05:18 -0700 [thread overview]
Message-ID: <4182DABE.7000502@candelatech.com> (raw)
In-Reply-To: <4182D44E.7070507@tpack.net>
Tommy Christensen wrote:
> Ben Greear wrote:
>
>> Tommy Christensen wrote:
>>> A return value > zero doesn't mean failure. It indicates congestion.
>>
>>
>>
>> Ok, but the skb is always deleted by the net_queue_xmit code if the
>> return is not zero? The difference between a hard-start-xmit failure
>> on eth0 when the hardware-queue is full and having a rate-limiting
>> queue drop a packet is virtually identical to me....
>
>
> For a virtual device: yes, dev_queue_xmit() drops the skb. What else
> could it do with it? The semantic is that dev_queue_xmit always consumes
> skb's given to it.
>
> A physical device will have a qdisc attached to it, so you don't get to
> see that the hardware queue is full. qdisc handles this case for you by
> retrying the transmission later. This is not (yet) congestion.
> OTOH if qdisc doesn't have room for a new skb in its *software* queue,
> the skb is dropped and congestion is reported upwards the stack.
Can't you also add a queue to a VLAN device?
eth1.1009 Link encap:Ethernet HWaddr 00:07:E9:1F:CE:02
inet addr:172.100.1.109 Bcast:172.100.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:2000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
I see fairly high latency when I overdrive the network, but it does seem to
work just fine.
>> pktgen registers this hook on the physical device when it starts
>> generating on
>> the physical device or any VLANs attached to it. To make a scheme
>> like this work
>> in general, we'd probably need a chain of callbacks instead of a
>> single method
>> pointer...
>
>
> Nice. This idea is definitely worth persuing. However, ideally we
> would want to be notified when the *qdisc* queue opens up - this
> is our "tx ring buffer".
Maybe the qdisc could automatically flush what it could to lower
level devices/queues whenever it was asked to enqueue a packet?
This way, waking the writers could automatically wake the various
queues under the writers.
That could be happening already, and might explain why my pktgen hacks
work.
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2004-10-30 0:05 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
2004-10-30 0:05 ` Ben Greear [this message]
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=4182DABE.7000502@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).