David Miller wrote:
From: Patrick McHardy <[EMAIL PROTECTED]>
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.
Its what the flow classifier does :)
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.
I see. I missed those discussions, but this has already been
agreed on, fine by me. It would still be preferable to use
queue_mapping instead of priority IMO, even if its activated
by a module parameter, since that leaves the option to use
classifiers.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
