netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).