Please consider these patches for 2.6.23 inclusion.
Updates since the last submission:
1. Fixed alloc_netdev_mq() queue_count bug.
2. Fixed the TCA_PRIO_MQ options layout.
3. Protected sch_prio and sch_rr multiqueue code with NET_SCH_MULTIQUEUE.
4. Added RTA_{GET|PUT}_FLAG in place of RTA_DATA
Please consider these patches for 2.6.23 inclusion.
These patches are built against Patrick McHardy's recently submitted
RTNETLINK nested compat attribute patches. They're needed to preserve
ABI between sch_{rr|prio} and iproute2.
Updates since the last submission:
1. Added checks for netif_sub
> PJ Waskiewicz wrote:
> > I did not modify other users of netif_queue_stopped() in
> > net/core/netpoll.c, net/core/dev.c, or net/core/pktgen.c, since no
> > classification occurs for the skb being sent to the device.
> > Therefore, packets should always be ending up in queue 0,
> so there's
PJ Waskiewicz wrote:
I did not modify other users of netif_queue_stopped() in net/core/netpoll.c,
net/core/dev.c, or net/core/pktgen.c, since no classification occurs for
the skb being sent to the device. Therefore, packets should always be
ending up in queue 0, so there's no need to check the s
Please consider these patches for 2.6.23 inclusion.
Updates since the last submission:
1. skb->queue_mapping moved into the iff cacheline. I looked at moving
iff and queue_mapping, but there wasn't enough room anywhere else to
logically group these in a different cacheline that I could see
From: Jan-Bernd Themann <[EMAIL PROTECTED]>
Date: Wed, 20 Jun 2007 16:58:43 +0200
> to me it seems that this patch set only include multiple transmit
> queue support (for qdisc). Am I right with this observation? If so,
> are there also plans to support multiple receive queues to allow the
> queue
> to me it seems that this patch set only include multiple
> transmit queue support (for qdisc). Am I right with this
> observation? If so, are there also plans to support multiple
> receive queues to allow the queues to be processed in
> parallel on different CPUs via a standard interface?
>
Hi,
to me it seems that this patch set only include multiple transmit queue support
(for qdisc). Am I right with this observation? If so, are there also plans to
support multiple receive queues to allow the queues to be processed in parallel
on different CPUs via a standard interface? Currently,
Please consider these patches for 2.6.23 inclusion.
This patchset is an updated version of previous multiqueue network device
support patches. The general approach of introducing a new API for multiqueue
network devices to register with the stack has remained. The changes include
adding a round-
