* Re: [PATCH] s2io: fixing a ethtool test that is broken
From: David Miller @ 2009-11-14 3:57 UTC (permalink / raw)
To: leitao; +Cc: netdev, sreenivasa.honnur
In-Reply-To: <1257882263-7507-1-git-send-email-leitao@linux.vnet.ibm.com>
From: leitao@linux.vnet.ibm.com
Date: Tue, 10 Nov 2009 14:44:23 -0500
> Due commit 4b77b0a2ba27d64f58f16d8d4d48d8319dda36ff, it is not more
> possible to pci_restore_state() more than once without calling
> pci_save_state() in the middle.
>
> Actually running a ethtool test on s2io makes the card inactive,
> and it needs to unload/reload the module to fix.
>
> This patch just save the state just after it restore in order to
> keep the old behaviour
>
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [patch] missing dev_put() on error path in vif_add()
From: David Miller @ 2009-11-14 3:57 UTC (permalink / raw)
To: ellre923; +Cc: error27, netdev
In-Reply-To: <4AFB77DA.3040600@gmail.com>
From: Wang Chen <ellre923@gmail.com>
Date: Thu, 12 Nov 2009 10:50:02 +0800
> Dan Carpenter said the following on 2009-11-11 20:03:
>> The other error paths in front of this one have a dev_put() but this one
>> got missed.
>>
>> Found by smatch static checker.
...
>> Signed-off-by: Dan Carpenter <error27@gmail.com>
...
> It's my fault. Introduced in 7dc00c82cbb0119cf4663f65bbaa2cc55f961db2.
>
> Acked-by: Wang Chen <ellre923@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-2.6] can: Fix driver Kconfig structure
From: David Miller @ 2009-11-14 3:58 UTC (permalink / raw)
To: oliver; +Cc: wg, netdev, socketcan-core
In-Reply-To: <4AFBF2E5.1090909@hartkopp.net>
From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Thu, 12 Nov 2009 12:35:01 +0100
> In 2.6.32-rc the new EMS USB CAN driver was contributed and added the Kconfig
> entry right behind an entry of the same *vendor*. This teared the SJA1000
> based driver selection into pieces.
>
> This fix cleans up the 2.6.32-rc Kconfig files for the CAN drivers and moves
> the SJA1000 and USB Kconfig portions into the belonging directories.
>
> As there are many new CAN drivers in the queue getting this cleanup into
> 2.6.32-rc would massively reduce the problems for the upcoming drivers.
>
> Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Applied.
^ permalink raw reply
* Re: [PATCH] can: add the missing netlink get_xstats_size callback
From: David Miller @ 2009-11-14 3:58 UTC (permalink / raw)
To: wg; +Cc: netdev, socketcan-core
In-Reply-To: <4AFC2AED.1090607@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Thu, 12 Nov 2009 16:34:05 +0100
> This patch adds the missing "get_xstats_size" callback for the
> netlink interface, which is required if "fill_xstats" is used,
> as pointed out by Patrick McHardy.
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Applied.
^ permalink raw reply
* Re: r8169: Fix receive buffer length when MTU is between 1515 and 1536
From: David Miller @ 2009-11-14 3:59 UTC (permalink / raw)
To: ray; +Cc: romieu, netdev
In-Reply-To: <4AFDC703.10902@apollo.lv>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] X25: Enable setting of cause and diagnostic fields
From: David Miller @ 2009-11-14 4:32 UTC (permalink / raw)
To: andrew.hendry; +Cc: netdev, linux-x25, linux-kernel
In-Reply-To: <d45a3acc0911111613v38fa9df4jed21876ce6309097@mail.gmail.com>
From: andrew hendry <andrew.hendry@gmail.com>
Date: Thu, 12 Nov 2009 11:13:27 +1100
> Adds SIOCX25SCAUSEDIAG, allowing X.25 programs to set the cause and
> diagnostic fields.
> Normally used to indicate status upon closing connections.
>
> Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
This change is incomplete.
You need to add handling to compat_x25_ioctl().
^ permalink raw reply
* Re: [patch 4/5] [PATCH] qeth: rework TSO functions
From: David Miller @ 2009-11-14 4:36 UTC (permalink / raw)
To: frank.blaschka; +Cc: netdev, linux-s390
In-Reply-To: <20091112101301.126320000@de.ibm.com>
From: frank.blaschka@de.ibm.com
Date: Thu, 12 Nov 2009 11:11:44 +0100
> From: Frank Blaschka <frank.blaschka@de.ibm.com>
>
> The maximum TSO size OSA can handle is 15 * PAGE_SIZE. This
> patch reduces gso_max_size to this value and adds some sanity
> checks and statistics to the TSO implementation.
> Since only layer 3 is able to do TSO move all TSO related functions
> to the qeth_l3 module.
>
> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Please don't add sysctl knobs for getting and setting TSO enabling,
that's what ethtool is for.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv6: use RCU to walk list of network devices
From: David Miller @ 2009-11-14 4:39 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, netdev
In-Reply-To: <4AFB8246.6060804@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 12 Nov 2009 04:34:30 +0100
> [PATCH net-next-2.6] ipv6: use RCU to walk list of network devices
>
> No longer need read_lock(&dev_base_lock), use RCU instead.
> We also can avoid taking references on inet6_dev structs.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] igmp: Use next_net_device_rcu()
From: David Miller @ 2009-11-14 4:39 UTC (permalink / raw)
To: shemminger; +Cc: eric.dumazet, netdev
In-Reply-To: <20091111211435.570b259a@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 11 Nov 2009 21:14:35 -0800
> On Thu, 12 Nov 2009 04:48:52 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> We need to use next_det_device_rcu() in RCU protected section.
>>
>> We also can avoid in_dev_get()/in_dev_put() overhead (code size mainly)
>> in rcu_read_lock() sections.
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/7] igb: change type for ring sizes to u16 in igb_set_ring_param
From: David Miller @ 2009-11-14 4:48 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20091113043604.1240.80142.stgit@localhost.localdomain>
All 7 patches applied, thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ixgbe: Flush the LSC mask change to prevent repeated interrupts
From: David Miller @ 2009-11-14 4:48 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, shannon.nelson
In-Reply-To: <20091113044709.1601.82693.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 12 Nov 2009 20:47:11 -0800
> From: Nelson, Shannon <shannon.nelson@intel.com>
>
> Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [patch 0/4] s390: networking patches for 2.6.33
From: David Miller @ 2009-11-14 4:49 UTC (permalink / raw)
To: ursula.braun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens
In-Reply-To: <20091113074626.078348000@linux.vnet.ibm.com>
From: Ursula Braun <ursula.braun@de.ibm.com>
Date: Fri, 13 Nov 2009 08:46:26 +0100
> here is a set of networking patches for 2.6.33.
>
> shortlog:
> Frank Blaschka (1)
> ctcm: suspend has to wait for outstanding I/O
>
> Ursula Braun (3)
> iucv: add work_queue cleanup for suspend
> s390: remove cu3088 layer for lcs and ctcm
> netiucv: displayed TX bytes value much too high
All applied, thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ixgbe: Make queue pairs on single MSI-X interrupts
From: David Miller @ 2009-11-14 4:49 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, peter.p.waskiewicz.jr
In-Reply-To: <20091113095035.2059.13992.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 13 Nov 2009 01:50:43 -0800
> From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
>
> This patch pairs similar-numbered Rx and Tx queues onto a single
> MSI-X vector. For example, Tx queue 0 and Rx queue 0's interrupt
> with be ethX-RxTx-0. This allows for more efficient cleanup, since
> fewer interrupts will be firing during device operation. It also
> helps with a cleaner CPU affinity for IRQ affinity.
>
> Signed-off-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: [PATCH] inet: fix inet_bind_bucket_for_each
From: David Miller @ 2009-11-14 4:49 UTC (permalink / raw)
To: lgrijincu; +Cc: netdev, opurdila
In-Reply-To: <200911121707.26224.lgrijincu@ixiacom.com>
From: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
Date: Thu, 12 Nov 2009 17:07:26 +0200
> The first "node" is supposed to be the cursor used in the for_each.
>
> The second "node" is ment literally and should not be macro expanded:
> it's the name of the hlist_node field from the inet_bind_bucket.
>
> This currently works because when inet_bind_bucket_for_each is called
> it's argument is still "node".
>
> Signed-off-by: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4: speedup inet_dump_ifaddr()
From: David Miller @ 2009-11-14 4:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, netdev
In-Reply-To: <4AFC4979.7030007@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 12 Nov 2009 18:44:25 +0100
> [PATCH net-next-2.6] ipv4: speedup inet_dump_ifaddr()
>
> When handling large number of netdevices, inet_dump_ifaddr()
> is very slow because it has O(N2) complexity.
>
> Instead of scanning one single list, we can use the NETDEV_HASHENTRIES
> sub lists of the dev_index hash table, and RCU lookups.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv6: speedup inet6_dump_addr()
From: David Miller @ 2009-11-14 4:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, shemminger
In-Reply-To: <4AFC17A6.4040801@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 12 Nov 2009 15:11:50 +0100
> When handling large number of netdevices, inet6_dump_addr()
> is very slow because it has O(N^2) complexity.
>
> Instead of scanning one single list, we can use the NETDEV_HASHENTRIES
> sub lists of the dev_index hash table, and RCU lookups.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] inetpeer: Optimize inet_getid()
From: David Miller @ 2009-11-14 4:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AFC62F5.60700@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 12 Nov 2009 20:33:09 +0100
> While investigating for network latencies, I found inet_getid() was a
> contention point for some workloads, as inet_peer_idlock is shared
> by all inet_getid() users regardless of peers.
>
> One way to fix this is to make ip_id_count an atomic_t instead
> of __u16, and use atomic_add_return().
>
> In order to keep sizeof(struct inet_peer) = 64 on 64bit arches
> tcp_ts_stamp is also converted to __u32 instead of "unsigned long".
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] Phonet: put protocols array under RCU
From: David Miller @ 2009-11-14 4:51 UTC (permalink / raw)
To: remi; +Cc: netdev, remi.denis-courmont
In-Reply-To: <1258124479-1167-1-git-send-email-remi@remlab.net>
From: Rémi Denis-Courmont <remi@remlab.net>
Date: Fri, 13 Nov 2009 17:01:18 +0200
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] Phonet: convert routing table to RCU
From: David Miller @ 2009-11-14 4:51 UTC (permalink / raw)
To: remi; +Cc: netdev, remi.denis-courmont
In-Reply-To: <1258124479-1167-2-git-send-email-remi@remlab.net>
From: Rémi Denis-Courmont <remi@remlab.net>
Date: Fri, 13 Nov 2009 17:01:19 +0200
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net/can: add driver for mscan family & mpc52xx_mscan
From: David Miller @ 2009-11-14 4:51 UTC (permalink / raw)
To: w.sang; +Cc: netdev, socketcan-core, linuxppc-dev, wg, grant.likely
In-Reply-To: <1258128892-28800-1-git-send-email-w.sang@pengutronix.de>
From: Wolfram Sang <w.sang@pengutronix.de>
Date: Fri, 13 Nov 2009 17:14:52 +0100
> Taken from socketcan-svn, fixed remaining todos, cleaned up, tested with a
> phyCORE-MPC5200B-IO and a custom board.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [RFC PATCH] net: add dataref destructor to sk_buff
From: Gregory Haskins @ 2009-11-14 5:27 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Herbert Xu, Gregory Haskins, Michael S. Tsirkin, alacrityvm-devel,
linux-kernel, netdev
In-Reply-To: <20091113184503.13f6d447@s6510>
[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]
Stephen Hemminger wrote:
> On Fri, 13 Nov 2009 21:27:57 -0500
> Gregory Haskins <gregory.haskins@gmail.com> wrote:
>
>> Herbert Xu wrote:
>>> On Fri, Nov 13, 2009 at 08:33:35PM -0500, Gregory Haskins wrote:
>>>> Well, not with respect to the overall protocol, of course not. But with
>>>> respect to the buffer in question, it _has_ to be. Or am I missing
>>>> something?
>>> sendfile() has never guaranteed that the kernel is finished with
>>> the underlying pages when it returns.
>>>
>>> Cheers,
>> Clearly there must be _some_ mechanism to synchronize (e.g.
>> flush/barrier) though, right? Otherwise, that interface would seem to
>> be quite prone to races and would likely be unusable. So what does
>> said flush use to know when the buffer is free?
>
> No all the interfaces require a copy.
I'm sorry, but I do not think that is correct. As others have pointed
out, that would not appear to be true for at least sendfile.
> Actually, sendfile makes no guarantee about synchronization
> because the receiver of said file could be arbitrarily slow, and any attempt at locking down
> current contents of file is a denial of service exposure.
I think you are inverting the problem space. It is fully expected that
changing the "file", or the pages that represent the file before the
packet is queued would constitute the modification of the stream on the
wire.
I am more thinking about the applications of mmap+sendfile to implement
a zero-copy interface. As David mentions in another mail, it seems that
there is no sync mechanism available, so this would not appear to be a
viable use case today, unfortunately.
>
> People have tried doing copy-less send by page flipping, but the overhead of the IPI to
> invalidate the TLB exceeded the overhead of the copy. There was an Intel paper on this in
> at Linux Symposium (Ottawa) several years ago.
I think you are confusing copy-less tx with copy-less rx. You can try
to do copy-less rx with page flipping, which has the IPI/TLB thrashing
properties you mention, and I agree is problematic. We are talking
about copy-less tx here, however, and therefore no page-flipping is
involved. Rather, we are just posting SG lists of pages directly to the
NIC (assuming the nic supports HIGH_DMA, etc). You do not need to flip
the page, or invalidate the TLB (and thus IPI the other cores) to do
this to my knowledge.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: Benjamin LaHaise @ 2009-11-14 6:24 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, opurdila, eric.dumazet, netdev
In-Reply-To: <20091113.185937.251557071.davem@davemloft.net>
On Fri, Nov 13, 2009 at 06:59:37PM -0800, David Miller wrote:
> From: Benjamin LaHaise <bcrl@lhnet.ca>
> Date: Fri, 13 Nov 2009 18:52:10 -0500
>
> > If you don't want the overhead from this kind of scaling, stick it under a
> > config option, but please don't stop other people from pushing Linux into
> > new uses which have these scaling requirements.
>
> This 'scaling requirement' only exists in environments where people
> undersubsribe their networks, right?
Depends on how you look at things. The case of lots of interfaces going
up/down can occur during normal operations. The incumbent telco in this
area has occasional flaps that reset thousands of sessions. The problem
relates to how things flop over to a different path within their network,
as they don't provide hot standby circuits for all the aggregated traffic
coming in -- a link down results in a flap of all the L2TP sessions. As
for it being underprovisioned, that doesn't really apply. The core LNS
boxes are kept from having saturated links, as that results in poor user
performance. Plus they have substantially more CPU than embedded routers.
> I'm not saying we won't put scaling into these areas, I'm just trying
> to make a point to show that this "need" only exists because people
> have purposefully created these situations where they feel the need to
> massively control their users usage in order to generate revenue.
I've finally got some of the userspace bits necessary for parallel network
device creation wired up. Will reducing the granularity of rtnl_lock() for
devices which can handle it be okay? That will get a factor of 4 to 8
improvement from current single socket hardware.
The other way I'm working around the scaling issues is to use network
namespaces. Babylon (the L2TP/PPPoE stack I'm working on) can now split
interface creation across some number of network namespaces. This keeps
the number of interfaces in a given net instance down to 5-10,000. That
really helps avoid some of the scaling issues, as we're pretty good in
that range.
The worst part of all the overhead during setup and teardown is that very
little traffic can pass while this is occurring, effectively making it an
outage, hence the desire to minimise outage situations.
-ben
^ permalink raw reply
* linux-next: net tree build failure
From: Stephen Rothwell @ 2009-11-14 6:50 UTC (permalink / raw)
To: David S. Miller, netdev
Cc: linux-next, linux-kernel, Arnaldo Carvalho de Melo
[-- Attachment #1: Type: text/plain, Size: 609 bytes --]
Hi Dave,
Today's linux-next build (alpha defconfig) failed like this:
arch/alpha/kernel/systbls.S:507: Error: .err encountered
Caused by commit a2e2725541fad72416326798c2d7fa4dafb7d337 ("net:
Introduce recvmmsg socket syscall") which added a syscall to the alpha
syscall table but forgot to update NR_SYSCALLS in
arch/alpha/include/asm/unistd.h (it also didn't add the __NR_ constant
thee either).
I suspect that this is true for a few other architectures as well
(including sparc?).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: Benny Amorsen @ 2009-11-14 7:08 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Benjamin LaHaise, Octavian Purdila, Eric Dumazet, netdev
In-Reply-To: <20091113144937.23693bb4@nehalam>
Stephen Hemminger <shemminger@vyatta.com> writes:
> Then maybe network devices aren't the right layering model. At some
> point the paradigm has to be re-examined.
I'm not quite sure where this becomes a problem. We have 1185 network
interfaces (VLAN's) on one box. Boot time is a problem, but other than
that it works ok. If something like this would help speed up booting,
that would be very nice.
/Benny
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
From: Eric Dumazet @ 2009-11-14 7:21 UTC (permalink / raw)
To: Benny Amorsen
Cc: Stephen Hemminger, Benjamin LaHaise, Octavian Purdila, netdev
In-Reply-To: <m3r5s1bn3f.fsf@ursa.amorsen.dk>
Benny Amorsen a écrit :
> Stephen Hemminger <shemminger@vyatta.com> writes:
>
>> Then maybe network devices aren't the right layering model. At some
>> point the paradigm has to be re-examined.
>
> I'm not quite sure where this becomes a problem. We have 1185 network
> interfaces (VLAN's) on one box. Boot time is a problem, but other than
> that it works ok. If something like this would help speed up booting,
> that would be very nice.
>
It would be very nice if you tell us why booting is very long,
ie what is done and how much time it takes.
It's clear that ~1000 vlans is quite reasonable :)
^ 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