* Re: [RFC Patch] net: reserve ports for applications using fixed port numbers
From: Cong Wang @ 2010-02-04 3:23 UTC (permalink / raw)
To: Octavian Purdila
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eric Dumazet,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Neil Horman, linux-sctp-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <201002031312.48531.opurdila-+zzKsuq53OdBDgjK7y7TUQ@public.gmane.org>
Octavian Purdila wrote:
> On Wednesday 03 February 2010 06:30:07 you wrote:
>
>> This patch introduces /proc/sys/net/ipv4/ip_local_reserved_ports,
>> it can be used like ip_local_port_range, but this is used to
>> reserve ports for third-party applications which use fixed
>> port numbers within ip_local_port_range.
>>
>> This only affects the applications which call socket functions
>> like bind(2) with port number 0, to prevent the kernel getting the ports
>> within the specified range for them. For applications which use fixed
>> port number, it will have no effects.
>
> It also affects the case where applications do connect, without previously
> doing bind, right?
Yeah, I forgot to mention this, sorry.
>
>> Any comments are welcome.
>
> I think it might be useful to allow setting individual ports as reserved, not
> only ranges, for example by using a bitmap.
>
This is a good idea, but I am not sure if this will be overkill? :-/
Also, using bitmap is not friendly to sysctl interface, I am afraid.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-2.6 PATCH 2/2] ixgbe: Fix return of invalid txq
From: David Miller @ 2010-02-04 3:17 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, krkumar2, jesse.brandeburg, peter.p.waskiewicz.jr
In-Reply-To: <20100203231309.15352.12337.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 03 Feb 2010 15:13:10 -0800
> From: Krishna Kumar <krkumar2@in.ibm.com>
>
> a developer had complained of getting lots of warnings:
>
> "eth16 selects TX queue 98, but real number of TX queues is 64"
>
> http://www.mail-archive.com/e1000-devel@lists.sourceforge.net/msg02200.html
>
> As there was no follow up on that bug, I am submitting this
> patch assuming that the other return points will not return
> invalid txq's, and also that this fixes the bug (not tested).
>
> Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/2] ixgbe: Fix ixgbe_tx_map error path
From: David Miller @ 2010-02-04 3:17 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, anton
In-Reply-To: <20100203231224.15352.27988.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 03 Feb 2010 15:12:51 -0800
> From: Anton Blanchard <anton@samba.org>
>
> Commit e5a43549f7a58509a91b299a51337d386697b92c (ixgbe: remove
> skb_dma_map/unmap calls from driver) looks to have introduced a bug in
> ixgbe_tx_map. If we get an error from a PCI DMA call, we loop backwards
> through count until it becomes -1 and return that.
>
> The caller of ixgbe_tx_map expects 0 on error, so return that instead.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2]netxen: tx timeout fix
From: David Miller @ 2010-02-04 3:15 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, dhananjay.phadke
In-Reply-To: <1265120181-1671-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Tue, 2 Feb 2010 06:16:19 -0800
> Hi
> Series of 2 patches to fix tx timeout recovery and
> null pointer exception while cleaning resources.
>
> Plz apply these to net-2.6 tree.
Both applied, thank you.
^ permalink raw reply
* Re: [PATCH 01/10] sfc: Update MCDI protocol definitions
From: David Miller @ 2010-02-04 3:13 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1265225294.2116.1.camel@achroite.uk.solarflarecom.com>
All 10 patches applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 01/86] dccp: fix bug in cache allocation
From: David Miller @ 2010-02-04 3:01 UTC (permalink / raw)
To: nhorman; +Cc: gerrit, dccp, netdev
In-Reply-To: <20100201115638.GB25094@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Mon, 1 Feb 2010 06:56:38 -0500
> On Mon, Feb 01, 2010 at 07:18:06AM +0100, Gerrit Renker wrote:
>> This fixes a bug introduced in commit de4ef86cfce60d2250111f34f8a084e769f23b16
>> ("dccp: fix dccp rmmod when kernel configured to use slub", 17 Jan): the
>> vsnprintf used sizeof(slab_name_fmt), which became truncated to 4 bytes, since
>> slab_name_fmt is now a 4-byte pointer and no longer a 32-character array.
>>
>> This lead to error messages such as
>> FATAL: Error inserting dccp: No buffer space available
>>
>> >> kernel: [ 1456.341501] kmem_cache_create: duplicate cache cci
>> generated due to the truncation after the 3rrdc character.
>>
>> Fixed for the moment by introducing a symbolic constant. Tested to fix the bug.
>>
>> Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
>
> These changes make sense, sorry for not seeing that earlier. Thanks!
>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/1] dccp: fix auto-loading of dccp(_probe)
From: David Miller @ 2010-02-04 3:01 UTC (permalink / raw)
To: nhorman; +Cc: gerrit, dccp, netdev
In-Reply-To: <20100203115840.GA651@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Wed, 3 Feb 2010 06:58:40 -0500
> On Wed, Feb 03, 2010 at 07:16:56AM +0100, Gerrit Renker wrote:
>> Hi Neil,
>>
>> I have tested your patch, it works fine thanks to the repeated execution of the macro
>> argument. I have reformatted it, removing the inner parentheses, which I think is
>> justified since macros copy their arguments in full. Also converted your email to a
>> drafted commit message. Due to this, have not copied your signed-off -- if you are
>> ok, please add, this should be submitted asap.
>>
> Understood, and thank you. This looks fine to me
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 07/10] drivers/net/amd8111e.c: Fix continuation line formats
From: David Miller @ 2010-02-04 2:44 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, netdev
In-Reply-To: <5f913ef7c2af30646e9c56eb4cb33a1d67d3a721.1264967500.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 31 Jan 2010 12:02:09 -0800
> String constants that are continued on subsequent lines with \
> are not good.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next-2.6 v2] can: add support for CAN interface cards based on the PLX90xx PCI bridge
From: David Miller @ 2010-02-04 2:39 UTC (permalink / raw)
To: wg; +Cc: P.B.Cheblakov, netdev, Socketcan-core
In-Reply-To: <4B673E19.40904@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Mon, 01 Feb 2010 21:48:25 +0100
> Pavel B. Cheblakov wrote:
>> From: Pavel Cheblakov <P.B.Cheblakov@inp.nsk.su>
>>
>> This driver is for CAN interface cards based on the PLX90xx PCI bridge.
>> Driver supports now:
>> - Adlink PCI-7841/cPCI-7841 card (http://www.adlinktech.com/)
>> - Adlink PCI-7841/cPCI-7841 SE card
>> - Marathon CAN-bus-PCI card (http://www.marathon.ru/)
>> - TEWS TECHNOLOGIES TPMC810 card (http://www.tews.com/)
>>
>> Changes since v1:
>> - Added some defines for static inline int plx_pci_check_sja1000(...)
>> - static struct pci_device_id plx_pci_tbl[] replaced by
>> static DEFINE_PCI_DEVICE_TABLE(plx_pci_tbl)
>> - Typo fixed
>>
>> Signed-off-by: Pavel Cheblakov <P.B.Cheblakov@inp.nsk.su>
>> Acked-by: Wolfgang Grandegger <wg@grandegger.com>
>
> Looks good now. The interface seems now generic enough to support other
> PLX09xx based CAN cards as well.
>
> Thanks for your contribution.
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next-2.6] cxgb3: add memory barriers
From: David Miller @ 2010-02-04 2:37 UTC (permalink / raw)
To: divy; +Cc: netdev, linux-kernel, swise, wenxiong
In-Reply-To: <20100201202929.23037.68116.stgit@speedy5.asicdesigners.com>
From: Divy Le Ray <divy@chelsio.com>
Date: Mon, 01 Feb 2010 12:29:29 -0800
> From: Divy Le Ray <divy@chelsio.com>
>
> Add memory barriers to fix crashes observed on newest PowerPC platforms.
> The HW and driver state of the receive rings were getting out of sync.
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] sky2: fix transmit DMA map leakage
From: David Miller @ 2010-02-04 2:34 UTC (permalink / raw)
To: shemminger; +Cc: jarkao2, mbreuer, netdev
In-Reply-To: <20100201154147.5bb0b2c7@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 1 Feb 2010 15:41:47 -0800
> The book keeping structure for transmit always had the flags value
> cleared so transmit DMA maps were never released correctly.
> Based on patch by Jarek Poplawski, problem observed by Michael Breuer.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied to net-2.6, and queued for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 4/4] MCS7830 USB-Ether: resume _with_ working link, via .reset_resume support
From: David Miller @ 2010-02-04 2:29 UTC (permalink / raw)
To: andi-5+Cda9B46AM
Cc: arnd-r2nGTMty4D4, dhollis-yI4QWewtAp2DvotElmWtJA,
pchang23-rphTv4pjVZMJGwgDXS7ZQA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100131125842.GD13435-p/qQFhXj4MHA4IYVXhSI5GHfThorsUsI@public.gmane.org>
From: Andreas Mohr <andi-5+Cda9B46AM@public.gmane.org>
Date: Sun, 31 Jan 2010 13:58:42 +0100
> ChangeLog:
> Implement .reset_resume support to retain a live network connection
> during suspend despite USB power loss.
> - rework operation to reference cached data in mcs7830_data and
> netdev->dev_addr
> - update netdev->dev_addr only in case new MAC was set successfully
> . Tests done:
> . ethtool -d pre-/post-suspend: register values match
> . running ssh session suspend, resume: works
> . ifdown device, suspend, resume: works
> . ifup, suspend, unplug, resume: WORKS (eth1 is removed, re-ifup of eth1
> after card replug works)
> . verified identical MAC in ifconfig post-resume
> (ok, should be verified on network side to be fully certain...)
>
>
> Keywords: suspend resume network connection dead interface down
>
> Signed-off-by: Andreas Mohr <andi-5+Cda9B46AM@public.gmane.org>
Applied net-next-2.6
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/4] MCS7830 USB-Ether: change register define
From: David Miller @ 2010-02-04 2:29 UTC (permalink / raw)
To: andi; +Cc: arnd, dhollis, pchang23, netdev, linux-usb
In-Reply-To: <20100131125833.GC13435@rhlx01.hs-esslingen.de>
From: Andreas Mohr <andi@lisas.de>
Date: Sun, 31 Jan 2010 13:58:33 +0100
> ChangeLog:
> - rename register, add comment
>
> Signed-off-by: Andreas Mohr <andi@lisas.de>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 2/4] MCS7830 USB-Ether: Spelling corrections
From: David Miller @ 2010-02-04 2:29 UTC (permalink / raw)
To: andi; +Cc: arnd, dhollis, pchang23, netdev, linux-usb
In-Reply-To: <20100131125826.GB13435@rhlx01.hs-esslingen.de>
From: Andreas Mohr <andi@lisas.de>
Date: Sun, 31 Jan 2010 13:58:26 +0100
> ChangeLog:
> - spelling corrections / whitespace
>
> Signed-off-by: Andreas Mohr <andi@lisas.de>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 1/4] MCS7830 USB-Ether: add Rx error support
From: David Miller @ 2010-02-04 2:29 UTC (permalink / raw)
To: andi; +Cc: arnd, dhollis, pchang23, netdev, linux-usb
In-Reply-To: <20100131125819.GA13435@rhlx01.hs-esslingen.de>
From: Andreas Mohr <andi@lisas.de>
Date: Sun, 31 Jan 2010 13:58:19 +0100
> ChangeLog:
> - evaluate Rx error statistics from trailing Rx status byte
> - add driver TODO list
> - add myself to authors
>
>
> Quilt series run-tested, based on 2.6.33-rc4 (net-2.6.git mcs7830 has idle history,
> should be good to go).
>
> Signed-off-by: Andreas Mohr <andi@lisas.de>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 2.6.27.7-9-pae #7 SMP 1/1] networking tcp: Writing tcp socket be atomic
From: David Miller @ 2010-02-04 2:19 UTC (permalink / raw)
To: johny; +Cc: kuznet, netdev, jmorris, kaber, linux-kernel
In-Reply-To: <DB4F116661E3B0428456BB7E379EF4BB3C5F57@MX.asimcotech.com>
From: "John Ye" <johny@asimco.com.cn>
Date: Thu, 4 Feb 2010 10:03:44 +0800
> The option TCP_ATOMIC is not a must. We can make atomic be default
> if the data size is less than a fixed size, just the same as pipe.
> For example, if the data size is less than 512, we don't split the
> data so it goes atomically.
This completely ignores the core issue.
And that is, for the second time, that the application is where such
atomicity guarentees should be implemented.
And because of that any implementation of your kernel changes are
inappropriate, TCP_ATOMIC socket option or not.
^ permalink raw reply
* Re: [RFC] NAPI as kobject proposal
From: David Miller @ 2010-02-04 2:17 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20100203175846.545d7e56@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 3 Feb 2010 17:58:46 -0800
> The usage model I see is wanting to have:
> 1. only some cores being used for receive traffic
> on single Rx devices (NAPI)
> 2. only some cores being used for receive traffic
> on legacy devices (non-NAPI)
> 3. being able to configure a set of cpus with same
> IRQ/cache when doing Rx multi-queue. Assign MSI-X
> IRQ per core and allow both HT on core to split
> that RX traffic.
>
> All this should be manageable by some user utility like irqbalance.
>
> #1 and #2 argue for a per device map (like irq_affinity) but
> #3 is harder; not sure the right API for that.
Do you think the people setting RPS maps aren't capable of
configuring IRQ affinities? :-)
^ permalink raw reply
* Re: [PATCH] netlink: fix for too early rmmod
From: David Miller @ 2010-02-04 2:14 UTC (permalink / raw)
To: kaber; +Cc: adobriyan, netdev, kuznet
In-Reply-To: <4B683CDD.4050804@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 02 Feb 2010 15:55:25 +0100
> Alexey Dobriyan wrote:
>> Netlink code does module autoload if protocol userspace is asking for is
>> not ready. However, module can dissapear right after it was autoloaded.
>> Example: modprobe/rmmod stress-testing and xfrm_user.ko providing NETLINK_XFRM.
>>
>> netlink_create() in such situation _will_ create userspace socket and
>> _will_not_ pin module. Now if module was removed and we're going to call
>> ->netlink_rcv into nothing:
>>
>> BUG: unable to handle kernel paging request at ffffffffa02f842a
>> ^^^^^^^^^^^^^^^^
>> modules are loaded near these addresses here
>>
>> ...
>>
>> If module was quickly removed after autoloading, return -E.
>>
>> Return -EPROTONOSUPPORT if module was quickly removed after autoloading.
>>
>> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
>> ---
>>
>> NOTE: due to commit 513c25000005257e5474f261bf27d4a3c1dff1e3
>> "[NETLINK]: Don't prevent creating sockets when no kernel socket is registered"
>> error should probably be -ENOENT, but I have no idea what this
>> pam-audit thing is.
>
> Quoting from the thread back then (couldn't find a public reference):
>
>> FC4 includes a pam-0.77-audit.patch which adds a pam module that
>> uses libaudit to probe for audit availability. It calls audit_open
>> and ignores connection refused but returns an pam error for all
>> other errors.
>
> The current version of libaudit properly checks for EPROTONOSUPPORT,
> but I don't know when this was fixed and whether we can assume the
> broken code is not used anymore.
In any event, the EPROTONOSUPPORT is being returned now in a case
that has been OOPS'ing. So I think it's safe to apply Alexey's
fix as-is, and that is what I have just done in net-2.6 :-)
Thanks!
^ permalink raw reply
* Re: [PATCH] af_key: fix netns ops ordering on module load/unload
From: David Miller @ 2010-02-04 2:11 UTC (permalink / raw)
To: eric.dumazet; +Cc: kronos.it, adobriyan, linux-kernel, netdev
In-Reply-To: <1265032590.2848.40.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 01 Feb 2010 14:56:30 +0100
> Le lundi 01 février 2010 à 14:50 +0100, Luca Tettamanti a écrit :
>> On Sat, Jan 30, 2010 at 1:53 PM, Alexey Dobriyan <adobriyan@gmail.com> wrote:
>
>> > [PATCH] af_key: fix netns ops ordering on module load/unload
>> >
>> > 1. After sock_register() returns, it's possible to create sockets,
>> > even if module still not initialized fully (blame generic module code
>> > for that!)
>> > 2. Consequently, pfkey_create() can be called with pfkey_net_id still not
>> > initialized which will BUG_ON in net_generic():
>> > kernel BUG at include/net/netns/generic.h:43!
>> > 3. During netns shutdown, netns ops should be unregistered after
>> > key manager unregistered because key manager calls can be triggered
>> > from xfrm_user module:
>> >
>> > general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>> > pfkey_broadcast+0x111/0x210 [af_key]
>> > pfkey_send_notify+0x16a/0x300 [af_key]
>> > km_state_notify+0x41/0x70
>> > xfrm_flush_sa+0x75/0x90 [xfrm_user]
>> > 4. Unregister netns ops after socket ops just in case and for symmetry.
>> >
>> > Reported by Luca Tettamanti.
>> >
>> > Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
>>
>> Tested-by: Luca Tettamanti <kronos.it@gmail.com>
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks everyone!
^ permalink raw reply
* RE: [PATCH 2.6.27.7-9-pae #7 SMP 1/1] networking tcp: Writing tcp socket be atomic
From: John Ye @ 2010-02-04 2:03 UTC (permalink / raw)
To: David Miller; +Cc: kuznet, netdev, jmorris, kaber, linux-kernel
In-Reply-To: <20100203.085249.98326242.davem@davemloft.net>
David,
Thanks.
The option TCP_ATOMIC is not a must.
We can make atomic be default if the data size is less than a fixed size, just the same as pipe.
For example, if the data size is less than 512, we don't split the data so it goes atomically.
John Ye
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: 2010年2月4日 0:53
To: John Ye
Cc: kuznet@ms2.inr.ac.ru; netdev@vger.kernel.org; jmorris@namei.org; kaber@coreworks.de; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.27.7-9-pae #7 SMP 1/1] networking tcp: Writing tcp socket be atomic
Locking belongs inside of the application, not in the kernel.
As evidenced by the fact that you had to add new socket options, the
application needs to be modified anyways.
It's therefore just as easy to add the appropriate locking to the
sequences where the application writes over the TCP socket. And
it avoids having to modify the kernel at all.
^ permalink raw reply
* Re: [PATCH 2.6.33 1/4] net: Micrel KSZ8841/2 PCI Ethernet driver
From: David Miller @ 2010-02-04 2:00 UTC (permalink / raw)
To: Tristram.Ha; +Cc: alan, shemminger, netdev, linux-kernel
In-Reply-To: <14385191E87B904DBD836449AA30269D021A4D@MORGANITE.micrel.com>
From: "Ha, Tristram" <Tristram.Ha@Micrel.Com>
Date: Fri, 29 Jan 2010 14:37:22 -0800
> This is a resubmission of the Micrel KSZ8841/2 PCI Ethernet driver.
The procfs stuff is a non-starter.
There will undoubtedly be other devices that have switch-like
facilities that we'd like to export configuration support for.
The last thing we want is a bunch of procfs files that each
driver decides the layout and behavior of.
We need a centralized way to config such things, and probably
the best is to have a rtnl_link_ops facility to get at the
ports and configure them with attribute blobs or similar.
We also said in your first submission that the way you're
getting at the bridge STP stuff with things like:
+/* Needed for STP support. */
+#ifdef CONFIG_KSZ8842_STP
+#include <../net/bridge/br_private.h>
+#endif
Yet you left all of this stuff in there.
^ permalink raw reply
* Re: [RFC] NAPI as kobject proposal
From: Stephen Hemminger @ 2010-02-04 1:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100203.173305.196876047.davem@davemloft.net>
On Wed, 03 Feb 2010 17:33:05 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Fri, 29 Jan 2010 10:18:39 -0800
>
> > As part of receive packet steering there is a requirement to add an
> > additional parameter to this for the CPU map.
>
> Hmmm, where did this come from?
>
> The RPS maps are per-device.
>
> I think I vaguely recall you "suggesting" that the RPS maps become
> per-NAPI.
>
> But, firstly, I didn't see any movement in that part of the
> discussion.
>
> And, secondly, I don't think this makes any sense at all.
>
> Things are already overly complicated as it is. Having the user know
> what traffic goes to a particular RX queue (ie. NAPI instance) and set
> the RPS map in some way specific to that RX queue is over the top.
>
> If the issue is the case of sharing a NAPI instance between two
> devices, there are a few other ways to deal with this.
>
> One I would suggest is to simply clone the RPS map amongst the
> devices sharing a NAPI instance.
>
> I currently see NAPI kobjects is just an over-abstraction for a
> perceived need rather than a real one.
It started with doing RPS, and not wanting to implement the proposed
sysfs interface (anything doing get_token is misuse of sysfs).
The usage model I see is wanting to have:
1. only some cores being used for receive traffic
on single Rx devices (NAPI)
2. only some cores being used for receive traffic
on legacy devices (non-NAPI)
3. being able to configure a set of cpus with same
IRQ/cache when doing Rx multi-queue. Assign MSI-X
IRQ per core and allow both HT on core to split
that RX traffic.
All this should be manageable by some user utility like irqbalance.
#1 and #2 argue for a per device map (like irq_affinity) but
#3 is harder; not sure the right API for that.
^ permalink raw reply
* Re: [RFC] [PATCH] net: Add support for ndo_select_queue() functions to cache the queue mapping
From: David Miller @ 2010-02-04 1:47 UTC (permalink / raw)
To: bhutchings; +Cc: shemminger, netdev, linux-net-drivers
In-Reply-To: <1264703676.2783.44.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 28 Jan 2010 18:34:34 +0000
> On Thu, 2010-01-28 at 10:00 -0800, Stephen Hemminger wrote:
>> Therefore the transmit hash and receiver hash will be different.
>
> The intent here is to make it worthwhile to calculate that expensive
> hash on the TX side.
I would rather something like this be implemented in a way
which is device hash agnostic.
And I believe it is possible to do this.
Anyways, why can't you just propagate the RX queue used by the flow to
the socket TX hash? We already store the RX queue in the SKB on
receive, the socket packet receive handling can simply propagate that
to the TX queue selector.
This would avoid having to do anything special in the driver's select
queue method. In any event, overriding the queue selection method,
while not absolutely forbidden, is very much discouraged. And if
this new scheme of yours creates another reason drivers will start
to override it, that's another negative in my book.
But most importantly, the last thing we want to do is calculate
something insane like Toeplitz, even if it's just once per connection.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/5] if_link: Add SR-IOV configuration methods
From: David Miller @ 2010-02-04 1:36 UTC (permalink / raw)
To: mitch.a.williams; +Cc: or.gerlitz, shemminger, jeffrey.t.kirsher, netdev, gospo
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FDD55CC06@rrsmsx501.amr.corp.intel.com>
From: "Williams, Mitch A" <mitch.a.williams@intel.com>
Date: Tue, 2 Feb 2010 09:45:41 -0700
> Dave and Stephen, please drop these patches. I'll update with the priority
> stuff and resubmit.
Okie dokie.
^ permalink raw reply
* Re: [RFC] NAPI as kobject proposal
From: David Miller @ 2010-02-04 1:33 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20100129101839.36944ba5@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 29 Jan 2010 10:18:39 -0800
> As part of receive packet steering there is a requirement to add an
> additional parameter to this for the CPU map.
Hmmm, where did this come from?
The RPS maps are per-device.
I think I vaguely recall you "suggesting" that the RPS maps become
per-NAPI.
But, firstly, I didn't see any movement in that part of the
discussion.
And, secondly, I don't think this makes any sense at all.
Things are already overly complicated as it is. Having the user know
what traffic goes to a particular RX queue (ie. NAPI instance) and set
the RPS map in some way specific to that RX queue is over the top.
If the issue is the case of sharing a NAPI instance between two
devices, there are a few other ways to deal with this.
One I would suggest is to simply clone the RPS map amongst the
devices sharing a NAPI instance.
I currently see NAPI kobjects is just an over-abstraction for a
perceived need rather than a real one.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox