From: David Miller <davem@davemloft.net>
To: kaber@trash.net
Cc: Ramkrishna.Vepa@neterion.com, Sreenivasa.Honnur@neterion.com,
netdev@vger.kernel.org, jeff@garzik.org, support@neterion.com
Subject: Re: [PATCH 2.6.25 2/4]S2io: Multiqueue network device support - FIFO selection based on L4 ports
Date: Wed, 20 Feb 2008 15:12:44 -0800 (PST) [thread overview]
Message-ID: <20080220.151244.79005114.davem@davemloft.net> (raw)
In-Reply-To: <47BCB304.9050709@trash.net>
From: Patrick McHardy <kaber@trash.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.
next prev parent reply other threads:[~2008-02-20 23:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-20 22:07 [PATCH 2.6.25 2/4]S2io: Multiqueue network device support - FIFO selection based on L4 ports Sreenivasa Honnur
2008-02-20 22:16 ` Patrick McHardy
2008-02-20 22:57 ` Ramkrishna Vepa
2008-02-20 23:08 ` Patrick McHardy
2008-02-20 23:12 ` David Miller [this message]
2008-02-20 23:15 ` Patrick McHardy
2008-02-20 23:18 ` David Miller
2008-02-20 23:21 ` Patrick McHardy
2008-02-20 23:49 ` Ramkrishna Vepa
2008-02-24 5:01 ` Jeff Garzik
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=20080220.151244.79005114.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=Ramkrishna.Vepa@neterion.com \
--cc=Sreenivasa.Honnur@neterion.com \
--cc=jeff@garzik.org \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=support@neterion.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).