All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.