[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080220.151244.79005114.davem@davemloft.net>
Date: Wed, 20 Feb 2008 15:12:44 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: kaber@...sh.net
Cc: Ramkrishna.Vepa@...erion.com, Sreenivasa.Honnur@...erion.com,
netdev@...r.kernel.org, jeff@...zik.org, support@...erion.com
Subject: Re: [PATCH 2.6.25 2/4]S2io: Multiqueue network device support -
FIFO selection based on L4 ports
From: Patrick McHardy <kaber@...sh.net>
Date: Thu, 21 Feb 2008 00:08:52 +0100
> Ramkrishna Vepa wrote:
> >> Sreenivasa Honnur wrote:
> >>
> >>> - Resubmit #2
> >>> - Transmit fifo selection based on TCP/UDP ports.
> >>> - Added tx_steering_type loadable parameter for transmit fifo
> >>>
> > selection.
> >
> >>> 0x0 NO_STEERING: Default FIFO is selected.
> >>> 0x1 TX_PRIORITY_STEERING: FIFO is selected based on skb->priority.
> >>> 0x2 TX_DEFAULT_STEERING: FIFO is selected based on L4 Ports.
> >>>
> >>>
> >> Why duplicate the generic multiqueue classification?
> >>
> > [Ram] Could you be more specific?
> >
>
> The generic multiqueue support classifies packets by setting
> skb->queue_mapping using qdisc classifiers, which is more
> flexible and avoids using module parameters.
But it doesn't do what these multiqueue TX queue hardware devices
want. These devices don't want packet scheduler "classification",
they want load balancing using some key (current cpu number,
hashing on the packet headers, etc.) And that's not what our
packet scheduler classifiers do or should do.
We don't want to have to tell people "you have to run 'tc' magic
foo to use all of the TX queues on your network card." That's
completely unreasonable and stupid.
We have to resolve this somehow, and there have been many discussions
about this a month or so ago.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists