> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Randy.Dunlap
> Sent: Monday, March 27, 2006 10:41 AM
> To: Stephen Hemminger
> Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]
> Subject: Re: net TODO
>
> On Mon, 20 Mar
From: "Randy.Dunlap" <[EMAIL PROTECTED]>
Date: Mon, 27 Mar 2006 10:40:42 -0800
> so Dave, can you just remove Documentation/networking/TODO ?
> or do you want a patch for that?
I'll kill it off.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL
On Mon, 20 Mar 2006 19:36:25 -0800 Stephen Hemminger wrote:
> On Mon, 20 Mar 2006 19:30:17 -0800
> "Randy.Dunlap" <[EMAIL PROTECTED]> wrote:
>
> >
> > in Documentation/networking/TODO, the Jamal netdev Rx polling API change
> > is done, right? (NAPI)
> >
> > Are any of the others done?
> > Sho
On Mon, 20 Mar 2006 19:30:17 -0800
"Randy.Dunlap" <[EMAIL PROTECTED]> wrote:
>
> in Documentation/networking/TODO, the Jamal netdev Rx polling API change
> is done, right? (NAPI)
>
> Are any of the others done?
> Should this TODO file be removed or updated or reference
> http://vger.kernel.or
:14 PM
> To: Leonid Grossman
> Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]
> Subject: Re: SKB tutorial, Blog, and NET TODO
>
> From: "Leonid Grossman" <[EMAIL PROTECTED]>
> Date: Sat, 30 Jul 2005 02:41:38 -0400
>
> > Some suggestions on how to proceed on rec
From: "Leonid Grossman" <[EMAIL PROTECTED]>
Date: Sat, 30 Jul 2005 02:41:38 -0400
> Some suggestions on how to proceed on receive side:
I've added your suggestions to:
http://vger.kernel.org/~davem/net_todo.html
sorry for taking so long to integrate...
-
To unsubscribe from this list: send
> Sent: Tuesday, July 12, 2005 12:20 PM
> To: [EMAIL PROTECTED]
> Cc: netdev@vger.kernel.org
> Subject: Re: SKB tutorial, Blog, and NET TODO
>
> From: "Leonid Grossman" <[EMAIL PROTECTED]>
> Date: Wed, 29 Jun 2005 14:11:13 -0700
>
> > - TSO supp
> I am not against reporting back (NETDEV_TX_CONTINUE or
> NETDEV_TX_GIVE_ME_THE_SAME_Q_AGAIN for example);
> what worries me is that the stopping of the queue being complex. As i
> said, I may be worrying too much and i will be proved wrong.
I understand, this schema will probably work perfectly
Sorry, I read my emails in a LIFO manner - typically that works well
with last email in thread covering all the previous, but occasionally
something is left over.
On Sat, 2005-23-07 at 18:14 +0200, Thomas Graf wrote:
> > i.e you map the time slots to weights and priorities on the rings to the
>
On Sun, 2005-24-07 at 18:04 -0700, David S. Miller wrote:
> But this simply doesn't work by itself, that's why we need the
> per-queue "stopped" states.
>
> We need something that properly synchronizes the queue "full"
> state transitions, so that the queue does not deadlock and when
> one priori
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Mon, 25 Jul 2005 03:24:37 +0200
> * David S. Miller <[EMAIL PROTECTED]> 2005-07-24 18:08
> > The next issue is how to demultiplex from the number of prios
> > we want, to what the hardware actually supports if the latter
> > is smaller.
>
> That's what
* David S. Miller <[EMAIL PROTECTED]> 2005-07-24 18:08
> The key is what should happen when the ring for prio X fills
> up? netif_stop_queue() in it's current form is the wrong
> thing to do, because it prevents lower priority packets from
> being queued which is exactly what we want to do if thos
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Sat, 23 Jul 2005 18:14:58 +0200
> The simplest case is if the hardware does strict prio and does
> the queueing itself based on skb->priority or similiar. We don't
> need to change anything in this case except for adding the
> interface to transfer the c
From: Jamal Hadi Salim <[EMAIL PROTECTED]>
Date: Sat, 23 Jul 2005 10:14:52 -0400
> Setting the skb->prio to be used by the driver sounds reasonable.
> Another alternative would be what was already mentioned to change the
> call to hardware_start_transmit() to take a prio option.
> The driver shoul
* Jamal Hadi Salim <[EMAIL PROTECTED]> 2005-07-23 10:14
> Most of these pieces of h/ware have different approaches to how those
> underlying rings are used sending out to the wire. As an example, it is
> clear the wireless folks have time slots + prios as the desired qos
> scheme. This will map nic
On Fri, 2005-22-07 at 15:52 -0700, David S. Miller wrote:
> Sounds OK. What happens if the top-level queue pulls out
> a packet with a certain priority, and that priority's queue
> in the device is stopped? Will it look for lower-priority
> packets and try to send those? All of this kind of log
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Fri, 22 Jul 2005 04:59:30 +0200
> We have multiple queue states, one for each hardware TX queue.
> But instead of multiple qdiscs per device we add a "prio"-argument
> to the dequeue-function. The top-level qdisc is dequeued with the
> highest active
David S. Miller wrote:
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 13 Jul 2005 01:38:37 +0200
If its about outgoing traffic, shouldn't a prio-qdisc as root qdisc do
just fine? skb->priority can be used to select a queue. Incoming traffic
with pre-classification by the NIC would require
On Tue, Jul 12, 2005 at 04:44:04PM -0700, David S. Miller wrote:
> > If its about outgoing traffic, shouldn't a prio-qdisc as root qdisc do
> > just fine? skb->priority can be used to select a queue. Incoming traffic
> > with pre-classification by the NIC would require multiple input queues
> > th
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 13 Jul 2005 01:38:37 +0200
> If its about outgoing traffic, shouldn't a prio-qdisc as root qdisc do
> just fine? skb->priority can be used to select a queue. Incoming traffic
> with pre-classification by the NIC would require multiple input queu
David S. Miller schrieb:
From: Zhu Yi <[EMAIL PROTECTED]>
Date: Thu, 30 Jun 2005 10:07:03 +0800
Agreed. The ipw2200 card provides 4 hardware queues for QoS. But current
network stack only supports one Tx queue.
This is actually difficult to implement support for.
Well, not difficult, but rath
From: "Leonid Grossman" <[EMAIL PROTECTED]>
Date: Wed, 29 Jun 2005 14:11:13 -0700
> - TSO support for IPv6
> - USO (UDP TSO) support
> - support for multiple hardware queues/channels and TCP traffic steering;
> there are number of benefits in the ability to associate TCP flows with a
> particular
From: Zhu Yi <[EMAIL PROTECTED]>
Date: Thu, 30 Jun 2005 10:07:03 +0800
> Agreed. The ipw2200 card provides 4 hardware queues for QoS. But current
> network stack only supports one Tx queue.
This is actually difficult to implement support for.
Well, not difficult, but rather I mean that it is cost
23 matches
Mail list logo
