* Re: [PATCH] udev: create empty regular files to represent net interfaces
From: Matt Domsch @ 2009-10-28 13:03 UTC (permalink / raw)
To: Kay Sievers
Cc: dann frazier, linux-hotplug, Narendra_K, netdev, Jordan_Hargrave,
Charles_Rose, Ben Hutchings
In-Reply-To: <ac3eb2510910280123g3c0e3d95wb38a239238906027@mail.gmail.com>
On Wed, Oct 28, 2009 at 09:23:57AM +0100, Kay Sievers wrote:
> On Tue, Oct 27, 2009 at 21:55, Matt Domsch <Matt_Domsch@dell.com> wrote:
> > On Thu, Oct 22, 2009 at 12:36:20AM -0600, dann frazier wrote:
> >> Here's a proof of concept to further the discussion..
> >>
> >> The default filename uses the format:
> >> ?? /dev/netdev/by-ifindex/$ifindex
> >>
> >> This provides the infrastructure to permit udev rules to create aliases for
> >> network devices using symlinks, for example:
> >>
> >> ?? /dev/netdev/by-name/eth0 -> ../by-ifindex/1
> >> ?? /dev/netdev/by-biosname/LOM0 -> ../by-ifindex/3
> >>
> >> A library (such as the proposed libnetdevname) could use this information
> >> to provide an alias->realname mapping for network utilities.
> >
> > yes, this could work, as IFINDEX is already exported in the uevents,
> > and that's the primary value udev needs to set up the mapping.
> >
> > While I like the little ifindex2name script you've got, I think udev
> > could simply call if_indextoname() to get this, and not call an
> > external program? ??I suppose it could be a really really simple
> > external program too.
>
> What's the point of all this? Why would udev ever need to find the
> name of a device by the ifindex? The device name is the primary value
> for the kernel events udev acts on.
Ultimately, udev doesn't care. I just want to use udev to keep track
of the pathname to device connections, like it does for all other
types of devices.
Applications such as net-tools, iproute, ethtool, etc. take a kernel
device name. I want to extend them to also take a path, and resolve
that path to a kernel device name. libnetdevname currently is _one
small function_ which does this. It need not even be in a library.
But whatever the mechanism, the path names need to be anchored
somewhere, so the library or all apps doing this kind of lookup know
where to look.
> That all sounds very much like something which will hit us back some
> day. I'm not sure, if udev should publish such dead text files in
> /dev, it does not seem to fit the usual APIs/assumptions where /sys
> and /dev match, and libudev provides access to both. It all sounds
> more like a database for a possible netdevname library, which does not
> need to be public in /dev, right?
Right, it doesn't need to be in /dev. We could have udev rules that
simply call yet another program to maintain that database, in yet
another way. But I really like how udev maintains the database of
symlinks for other device types, using symlinks in /dev/, and which
people are quite familiar with. Why can't it be extended to do
likewise for network device names too?
There is a completely different approach possible here, if people
don't want to use something like /dev to track device name aliases.
We could put the whole name alias mechanism in the kernel, with new
netlink commands to add/remove/list aliases (and now we've overloaded that
term, as the old eth0:1 "alias" and dmz -> eth1 "alias" wouldn't be
the same thing). But that idea hasn't met with a lot of interest
either.
--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
^ permalink raw reply
* Re: [PATCH 2/3] net: TCP thin linear timeouts
From: Arnd Hannemann @ 2009-10-28 12:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andreas Petlund, netdev, linux-kernel, shemminger, ilpo.jarvinen,
davem
In-Reply-To: <4AE7262B.1060703@gmail.com>
Eric Dumazet schrieb:
> Andreas Petlund a écrit :
>> This patch will make TCP use only linear timeouts if the stream is thin. This will help to avoid the very high latencies that thin stream suffer because of exponential backoff. This mechanism is only active if enabled by iocontrol or syscontrol and the stream is identified as thin.
>>
>
> Wont this reduce the session timeout to something very small, ie 15 retransmits, way under the minute ?
The session timeout no longer depends on the actual number of retransmits. Instead its a time interval,
which is roughly equivalent to the time a TCP, performing exponential backoff would need to perform
15 retransmits.
However, addressing the proposal:
I wonder how one can seriously suggest to just skip congestion response during timeout-based
loss recovery? I believe that in a heavily congested scenarios, this would lead to a goodput
goodput disaster... Not to mention that in a heavily congested scenario, suddenly every flow
will become "thin", so this will even amplify the problems. Or did I miss something?
Best regards,
Arnd
^ permalink raw reply
* Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
From: Tobi Oetiker @ 2009-10-28 12:55 UTC (permalink / raw)
To: Karol Lewandowski
Cc: Mel LKML, Mel Gorman, Frans Pop, Jiri Kosina, Sven Geggus,
Rafael J. Wysocki, David Miller, Reinette Chatre, Kalle Valo,
David Rientjes, KOSAKI Motohiro, Mohamed Abbas, Jens Axboe,
John W. Linville, Pekka Enberg, Bartlomiej Zolnierkiewicz,
Greg Kroah-Hartman, Stephan von Krawczynski, Kernel Testers List,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
In-Reply-To: <20091028114208.GA14476-nLtalAL5mPp2RxbNQum0x1nzlInOXLuq@public.gmane.org>
Today Karol Lewandowski wrote:
> On Sat, Oct 24, 2009 at 02:46:56PM +0100, Mel LKML wrote:
> > Hi,
>
> Hi,
>
> > On 10/23/09, Karol Lewandowski <karol.k.lewandowski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > On Fri, Oct 23, 2009 at 06:58:10PM +0200, Karol Lewandowski wrote:
>
> > > Ok, I've tested patches 1+2+4 and bug, while very hard to trigger, is
> > > still present. I'll test complete 1-4 patchset as time permits.
>
> Sorry for silence, I've been quite busy lately.
>
>
> > And also patch 5 please which is the revert. Patch 5 as pointed out is
> > probably a red herring. Hwoever, it has changed the timing and made a
> > difference for some testing so I'd like to know if it helps yours as
> > well.
>
> I've tested patches 1+2+3+4 in my normal usage scenario (do some work,
> suspend, do work, suspend, ...) and it failed today after 4 days (== 4
> suspend-resume cycles).
I have been testing 1+2,1+2+3 as well as 3+4 and have been of the
assumption that 3+4 does help ... I have now been runing a modified
version of 4 which prints a warning instead of doing anything ... I
have now seen the allocation issue again without the warning being
printed. So in other words
1+2+3 make the problem less severe, but do not solve it
4 seems to be a red hering.
cheers
tobi
--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi-7K0TWYW2a3pyDzI6CaY1VQ@public.gmane.org ++41 62 775 9902 / sb: -9900
^ permalink raw reply
* [PATCH]udev:Extend udev to support move events
From: Narendra K @ 2009-10-28 12:46 UTC (permalink / raw)
To: linux-hotplug
Cc: netdev, matt_domsch, jordan_hargrave, charles_rose,
sandeep_k_shandilya, dannf
As of now, udev does not support move events that are generated when
network interfaces are renamed. This patch extends udev to support move
events. With this patch udev would support rules like
ACTION=="move", SUBSYSTEM=="net", PROGRAM="netif_id %k"
Signed-off-by: Narendra K <Narendra_K@dell.com>
---
udev/udev-event.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/udev/udev-event.c b/udev/udev-event.c
index f4d7121..4a77753 100644
--- a/udev/udev-event.c
+++ b/udev/udev-event.c
@@ -647,6 +647,13 @@ exit_add:
goto exit;
}
+ /* handle "move" event */
+ if (strcmp(udev_device_get_subsystem(dev), "net") == 0 && strcmp(udev_device_get_action(dev), "move") == 0) {
+ udev_rules_apply_to_event(rules, event);
+ udev_device_update_db(dev);
+ goto exit;
+ }
+
/* remove device node */
if (major(udev_device_get_devnum(dev)) != 0 && strcmp(udev_device_get_action(dev), "remove") == 0) {
/* import database entry and delete it */
--
With regards,
Narendra K
^ permalink raw reply related
* Re: [PATCH V2]NET/KS8695: add support NAPI for Rx
From: David Miller @ 2009-10-28 12:14 UTC (permalink / raw)
To: dsilvers; +Cc: figo1802, netdev, ben
In-Reply-To: <20091028120643.GA7883@digital-scurf.org>
From: Daniel Silverstone <dsilvers@simtec.co.uk>
Date: Wed, 28 Oct 2009 12:06:44 +0000
> I see that Dave Miller has accepted your patch into net-next-2.6.
> I'd like to see the above fixed before that gets merged any further.
Any such change would need to be relative to what's already
in net-next-2.6
^ permalink raw reply
* Re: [PATCH V2]NET/KS8695: add support NAPI for Rx
From: Daniel Silverstone @ 2009-10-28 12:06 UTC (permalink / raw)
To: Figo.zhang; +Cc: David S. Miller, netdev, Ben Dooks
In-Reply-To: <1256653422.2148.23.camel@myhost>
On Tue, Oct 27, 2009 at 10:23:42PM +0800, Figo.zhang wrote:
> for wan, irq = 29; for lan ,irq = 16.
> so we can do this read the interrupt status:
>
> unsigned long mask_bit = 1 << ksp->rx_irq;
> status = readl(KS8695_IRQ_VA + KS8695_INTST);
I hate that there's no proper IRQ functions for managing these, as Ben has
commented. Although I can understand that writing such is beyond the scope of
this patch.
> #define MODULENAME "ks8695_ether"
> #define MODULEVERSION "1.01"
You still didn't update the module version. This is a pity because you've
potentially radically changed behaviour and you definitely have radically
changed implementation.
> + struct napi_struct napi;
> + spinlock_t rx_lock;
You have not added documentation for these fields in the structure's
documentation string.
> + * Use NAPI to receive packets.
"Inform NAPI that packet reception needs to be scheduled." might be better.
> +static int ks8695_rx(struct net_device *ndev, int budget)
This routine lacks a documentation string. Please write one.
> - /* Kick the RX DMA engine, in case it became suspended */
> - ks8695_writereg(ksp, KS8695_DRSC, 0);
I can't see where you have moved this to. Without it, sometimes the KS8695's
RX DMA engine will falter and packets won't be transferred properly.
> +static int ks8695_poll(struct napi_struct *napi, int budget)
This routine also lacks a documentation string.
> + netif_napi_add(ndev, &ksp->napi, ks8695_poll, 64);
This '64' seems quite arbitrary. Is it a standard default? Did you work it out
from something else? Some explanation would be nice.
I see that Dave Miller has accepted your patch into net-next-2.6. I'd like to
see the above fixed before that gets merged any further.
Regards,
Daniel.
--
Daniel Silverstone http://www.simtec.co.uk/
^ permalink raw reply
* RE: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: Kumar Gopalpet-B05799 @ 2009-10-28 12:00 UTC (permalink / raw)
To: netdev; +Cc: David Miller
In-Reply-To: <20091028.024325.134189895.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Wednesday, October 28, 2009 3:13 PM
>To: Kumar Gopalpet-B05799
>Cc: netdev@vger.kernel.org
>Subject: Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for
>etsec2.0 devices.
>
>From: Sandeep Gopalpet <sandeep.kumar@freescale.com>
>Date: Tue, 27 Oct 2009 22:25:18 +0530
>
>> This patch adds mdio support for etsec2.0 devices.
>>
>> Modified the fsl_pq_mdio structure to include the new mdio members.
>>
>> Signed-off-by: Sandeep Gopalpet <sandeep.kumar@freescale.com>
>
>This is the third time you've submitted this patch, and for
>the third time it DOES NOT apply to net-next-2.6 at all when I
>try to apply this gianfar patch series.
>
>You must be patching against another tree that has some
>changes that conflict with this one.
>
I had rebased and tested on the master branch of the following tree
http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
(The git protocol clone was not working, hence we used http)
If this is not the right tree, kindly correct me.
I could not find any other net-next-2.6 tree/branch on kernel.org.
I have updated the tree again, (though there is no change)
the last commit on the tree being :
commit b37b62fea1d1bf68ca51818f8eb1035188efd030
Author: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri Oct 23 08:33:42 2009 +0000
sfc: Rename 'xfp' file and functions to reflect reality
The 'XFP' driver is really a driver for the QT2022C2 and QT2025C
PHYs,
covering both more and less than XFP. Rename its functions and
constants to reflect reality and to reduce namespace pollution when
sfc is a built-in driver.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Also, I have merged it with the latest linux-next tree
(It is already updated with the net-next-2.6.git)
>Sort this out before submitting this again.
I am working on it.
>
>If you submit once more this same series, and it doesn't apply
>properly to net-next-2.6, I will flat our ignore your
>submissions for a week or so.
>
>You are wasting that much of my time by doing this over and over.
I apologize for that.
>
>Get your act together.
>
^ permalink raw reply
* Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
From: Mel Gorman @ 2009-10-28 11:59 UTC (permalink / raw)
To: Karol Lewandowski
Cc: Mel LKML, Frans Pop, Jiri Kosina, Sven Geggus, Tobias Oetiker,
Rafael J. Wysocki, David Miller, Reinette Chatre, Kalle Valo,
David Rientjes, KOSAKI Motohiro, Mohamed Abbas, Jens Axboe,
John W. Linville, Pekka Enberg, Bartlomiej Zolnierkiewicz,
Greg Kroah-Hartman, Stephan von Krawczynski, Kernel Testers List,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
In-Reply-To: <20091028114208.GA14476-nLtalAL5mPp2RxbNQum0x1nzlInOXLuq@public.gmane.org>
On Wed, Oct 28, 2009 at 12:42:08PM +0100, Karol Lewandowski wrote:
> On Sat, Oct 24, 2009 at 02:46:56PM +0100, Mel LKML wrote:
> > Hi,
>
> Hi,
>
> > On 10/23/09, Karol Lewandowski <karol.k.lewandowski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > On Fri, Oct 23, 2009 at 06:58:10PM +0200, Karol Lewandowski wrote:
>
> > > Ok, I've tested patches 1+2+4 and bug, while very hard to trigger, is
> > > still present. I'll test complete 1-4 patchset as time permits.
>
> Sorry for silence, I've been quite busy lately.
>
>
> > And also patch 5 please which is the revert. Patch 5 as pointed out is
> > probably a red herring. Hwoever, it has changed the timing and made a
> > difference for some testing so I'd like to know if it helps yours as
> > well.
>
> I've tested patches 1+2+3+4 in my normal usage scenario (do some work,
> suspend, do work, suspend, ...) and it failed today after 4 days (== 4
> suspend-resume cycles).
>
> I'll test 1-5 now.
>
I was digging through commits for suspend-related changes. Rafael, is
there any chance that some change to suspend is responsible for this
regression? This commit for example is a vague possibility;
c6f37f12197ac3bd2e5a35f2f0e195ae63d437de: PM/Suspend: Do not shrink memory before suspend
I say vague because FREE_PAGE_NUMBER is so small.
Also, what was the behaviour of the e100 driver when suspending before
this commit?
6905b1f1a03a48dcf115a2927f7b87dba8d5e566: Net / e100: Fix suspend of devices that cannot be power managed
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
From: Karol Lewandowski @ 2009-10-28 11:42 UTC (permalink / raw)
To: Mel LKML
Cc: Karol Lewandowski, Mel Gorman, Frans Pop, Jiri Kosina,
Sven Geggus, Tobias Oetiker, Rafael J. Wysocki, David Miller,
Reinette Chatre, Kalle Valo, David Rientjes, KOSAKI Motohiro,
Mohamed Abbas, Jens Axboe, John W. Linville, Pekka Enberg,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman,
Stephan von Krawczynski, Kernel Testers List,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
"linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org" <li
In-Reply-To: <9ec2d7290910240646p75b93c68v6ea1648d628a9660-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sat, Oct 24, 2009 at 02:46:56PM +0100, Mel LKML wrote:
> Hi,
Hi,
> On 10/23/09, Karol Lewandowski <karol.k.lewandowski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Fri, Oct 23, 2009 at 06:58:10PM +0200, Karol Lewandowski wrote:
> > Ok, I've tested patches 1+2+4 and bug, while very hard to trigger, is
> > still present. I'll test complete 1-4 patchset as time permits.
Sorry for silence, I've been quite busy lately.
> And also patch 5 please which is the revert. Patch 5 as pointed out is
> probably a red herring. Hwoever, it has changed the timing and made a
> difference for some testing so I'd like to know if it helps yours as
> well.
I've tested patches 1+2+3+4 in my normal usage scenario (do some work,
suspend, do work, suspend, ...) and it failed today after 4 days (== 4
suspend-resume cycles).
I'll test 1-5 now.
Thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] be2net:Changes to update ethtool get_settings function to return appropriate values.
From: David Miller @ 2009-10-28 11:15 UTC (permalink / raw)
To: sarveshwarb; +Cc: netdev
In-Reply-To: <20091022132949.GA23701@serverengines.com>
From: Sarveshwar Bandi <sarveshwarb@serverengines.com>
Date: Thu, 22 Oct 2009 19:00:00 +0530
> Update ethtool get_settings function to:
> - get current link speed settings from controller
> - get port transceiver type from controller
> - fill appropriate values for supported, phy_address
>
> Signed-off-by: Sarveshwar Bandi <sarveshwarb@serverengines.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] e100: Fix to allow systems with FW based cards to resume from STD
From: David Miller @ 2009-10-28 11:14 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, david.graham
In-Reply-To: <20091023025904.7057.58001.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 22 Oct 2009 19:59:29 -0700
> From: David Graham <david.graham@intel.com>
>
> Devices with loadable firmware must have their firmware reloaded
> after the system resumes from sleep, but the request_firmare()
> API is not available at this point in the resume flow because
> tasks are not yet running, and the system will hang if it is
> called. Work around this issue by only calling request_firmware()
> for a device's first firmware load, and cache a copy of the pointer
> to the firmware blob for that device, so that we may reload firmware
> images even during resume.
>
> Signed-off-by: David Graham <david.graham@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] vmxnet3: remove duplicated #include
From: David Miller @ 2009-10-28 11:13 UTC (permalink / raw)
To: sbhatewara; +Cc: netdev, weiyi.huang, pv-drivers
In-Reply-To: <alpine.LRH.2.00.0910221634130.23769@sbhatewara-dev1.eng.vmware.com>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Thu, 22 Oct 2009 16:58:33 -0700 (PDT)
>
>
> Remove duplicate headerfile includes from vmxnet3_int.h
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
> Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
> Signed-off-by: Bhavesh Davda <davda@vmware.com>
This patch doesn't apply to net-next-2.6, please resend.
^ permalink raw reply
* Re: [PATCH NEXT 0/6] netxen: changes for new chip
From: David Miller @ 2009-10-28 11:11 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1256436243-5736-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sat, 24 Oct 2009 19:03:57 -0700
> Series of 6 patches for net-next-2.6, please apply.
All applied, thanks.
^ permalink raw reply
* Re: [PATCH] virtio-net: fix data corruption with OOM
From: David Miller @ 2009-10-28 11:03 UTC (permalink / raw)
To: rusty; +Cc: netdev, mst
In-Reply-To: <200910282126.58902.rusty@rustcorp.com.au>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Wed, 28 Oct 2009 21:26:58 +1030
> On Tue, 27 Oct 2009 11:57:20 am you wrote:
>> Anything in a reply to a patch that looks like a signoff or ACK,
>> patchwork adds to the commit message in the mbox blob it spits out for
>> me.
>
> In case this got lost in the meta-discussion:
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: Corrected spelling error heurestics->heuristics
From: David Miller @ 2009-10-28 11:02 UTC (permalink / raw)
To: apetlund; +Cc: netdev, trivial, linux-kernel, ilpo.jarvinen
In-Reply-To: <4AE6F539.1020107@simula.no>
From: Andreas Petlund <apetlund@simula.no>
Date: Tue, 27 Oct 2009 14:27:21 +0100
> Corrected a spelling error in a function name.
>
> Signed-off-by: Andreas Petlund <apetlund@simula.no>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: sysfs: ethtool_ops can be NULL
From: David Miller @ 2009-10-28 11:02 UTC (permalink / raw)
To: andy; +Cc: eric.dumazet, netdev
In-Reply-To: <20091026134033.GD1639@gospo.rdu.redhat.com>
From: Andy Gospodarek <andy@greyhouse.net>
Date: Mon, 26 Oct 2009 09:40:33 -0400
> On Mon, Oct 26, 2009 at 12:23:33PM +0100, Eric Dumazet wrote:
>> commit d519e17e2d01a0ee9abe083019532061b4438065
>> (net: export device speed and duplex via sysfs)
>> made the wrong assumption that netdev->ethtool_ops was always set.
>>
>> This makes possible to crash kernel and let rtnl in locked state.
>>
>> modprobe dummy
>> ip link set dummy0 up
>> (udev runs and crash)
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
...
> Nice catch, Eric.
>
> Acked-by: Andy Gospodarek <andy@greyhouse.net>
Applied.
^ permalink raw reply
* Re: [PATCH] via-velocity: Remove private device list
From: David Miller @ 2009-10-28 11:02 UTC (permalink / raw)
To: ben; +Cc: romieu, netdev
In-Reply-To: <1256501329.3136.109.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sun, 25 Oct 2009 20:08:49 +0000
> via-velocity maintains a list of its devices in order to determine
> whether a netdev notification applies to one of them. That can be
> determined simply by checking the netdev_ops pointer, so the list can
> be removed.
>
> Compile-tested only.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Looks good to me, applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH V2]NET/KS8695: add support NAPI for Rx
From: Ben Dooks @ 2009-10-28 10:57 UTC (permalink / raw)
To: Figo.zhang; +Cc: David S. Miller, netdev
In-Reply-To: <1256653422.2148.23.camel@myhost>
Figo.zhang wrote:
> Add support NAPI Rx API for KS8695NET driver.
>
> v2, change the Rx function to NAPI.
>
> in <KS8695X Integrated Multi-port Gateway Solution Register Description
> v1.0>:
>
> Interrupt Enable Register (offset 0xE204)
> Bit29 : WAN MAC Receive Interrupt Enable
> Bit16 : LAN MAC Receive Interrupt Enable
>
> Interrupt Status Register (Offset 0xF208)
> Bit29: WAN MAC Receive Status
> Bit16: LAN MAC Receive Status
>
> see arch/arm/mach-ks8695/devices.c:
> ks8695_wan_resources[] and ks8695_lan_resources[]
> have IORESOURCE_IRQ , it have define the RX irq,
> for wan, irq = 29; for lan ,irq = 16.
> so we can do this read the interrupt status:
>
> unsigned long mask_bit = 1 << ksp->rx_irq;
> status = readl(KS8695_IRQ_VA + KS8695_INTST);
It would be nice to see some form of API addition to
the interrupt system to ack interrupts that have been
handled like this, since the irq layer is already
tracking the necessary IRQ->handler mappings.
--
Ben Dooks, Software Engineer, Simtec Electronics
http://www.simtec.co.uk/
^ permalink raw reply
* Re: [PATCH 2/2] tc35815: Enable NAPI
From: David Miller @ 2009-10-28 10:57 UTC (permalink / raw)
To: anemo; +Cc: netdev, ralf.roesch
In-Reply-To: <1256564782-2781-2-git-send-email-anemo@mba.ocn.ne.jp>
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Mon, 26 Oct 2009 22:46:22 +0900
> This driver has NAPI code but it has been disabled. Enable it now.
> The non-napi code will be removed lator.
>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Applied.
Please remove the NAPI enabling macro and the tests for it.
NAPI support should be unconditional.
If people want to test the pre-NAPI behavior, they can check
out an older copy of the driver quite easily.
Thanks.
^ permalink raw reply
* Re: [PATCH] virtio-net: fix data corruption with OOM
From: Rusty Russell @ 2009-10-28 10:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev, mst
In-Reply-To: <20091026.182720.81248604.davem@davemloft.net>
On Tue, 27 Oct 2009 11:57:20 am you wrote:
> Anything in a reply to a patch that looks like a signoff or ACK,
> patchwork adds to the commit message in the mbox blob it spits out for
> me.
In case this got lost in the meta-discussion:
Subject: virtio-net: fix data corruption with OOM
Date: Sun, 25 Oct 2009 19:03:40 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
virtio net used to unlink skbs from send queues on error,
but ever since 48925e372f04f5e35fec6269127c62b2c71ab794
we do not do this. This causes guest data corruption and crashes
with vhost since net core can requeue the skb or free it without
it being taken off the list.
This patch fixes this by queueing the skb after successful
transmit.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (+ comment)
---
drivers/net/virtio_net.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -516,8 +516,7 @@ again:
/* Free up any pending old buffers before queueing new ones. */
free_old_xmit_skbs(vi);
- /* Put new one in send queue and do transmit */
- __skb_queue_head(&vi->send, skb);
+ /* Try to transmit */
capacity = xmit_skb(vi, skb);
/* This can happen with OOM and indirect buffers. */
@@ -531,8 +530,17 @@ again:
}
return NETDEV_TX_BUSY;
}
+ vi->svq->vq_ops->kick(vi->svq);
- vi->svq->vq_ops->kick(vi->svq);
+ /*
+ * Put new one in send queue. You'd expect we'd need this before
+ * xmit_skb calls add_buf(), since the callback can be triggered
+ * immediately after that. But since the callback just triggers
+ * another call back here, normal network xmit locking prevents the
+ * race.
+ */
+ __skb_queue_head(&vi->send, skb);
+
/* Don't wait up for transmitted skbs to be freed. */
skb_orphan(skb);
nf_reset(skb);
^ permalink raw reply
* Re: [PATCH 1/2] tc35815: Fix return value of tc35815_do_interrupt when NAPI enabled
From: David Miller @ 2009-10-28 10:57 UTC (permalink / raw)
To: anemo; +Cc: netdev, ralf.roesch
In-Reply-To: <1256564782-2781-1-git-send-email-anemo@mba.ocn.ne.jp>
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Mon, 26 Oct 2009 22:46:21 +0900
> Return received count correctly even if tx completed at the same time.
> Currently NAPI is disabled for this driver so this patch does not fix
> any real problem.
>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Applied.
^ permalink raw reply
* Re: [PATCH V2]NET/KS8695: add support NAPI for Rx
From: David Miller @ 2009-10-28 10:55 UTC (permalink / raw)
To: figo1802; +Cc: dsilvers, netdev, ben
In-Reply-To: <1256653422.2148.23.camel@myhost>
From: "Figo.zhang" <figo1802@gmail.com>
Date: Tue, 27 Oct 2009 22:23:42 +0800
> Add support NAPI Rx API for KS8695NET driver.
>
> v2, change the Rx function to NAPI.
...
> Signed-off-by: Figo.zhang <figo1802@gmail.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH net-2.6] sfc: Really allow RX checksum offload to be disabled
From: Ben Hutchings @ 2009-10-28 10:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <20091028.024940.181264224.davem@davemloft.net>
On Wed, 2009-10-28 at 02:49 -0700, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Tue, 27 Oct 2009 19:44:33 +0000
>
> > We have never checked the efx_nic::rx_checksum_enabled flag everywhere
> > we should, and since the switch to GRO we don't check it anywhere.
> > It's simplest to check it in the one place where we initialise the
> > per-packet checksummed flag.
> >
> > Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> > Cc: stable@kernel.org
> > ---
> > I'm not sure whether this is serious enough to merit a stable update.
> > It's not a recent regression.
>
> This patch only applies to net-next-2.6, so I can't see how it could
> be a -stable candidate :-)
>
> So I've applied it there.
The register name update in net-next-2.6 changed the context for this
patch. I'll send a new patch that will apply to the earlier versions.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-2.6] sfc: Set ip_summed correctly for page buffers passed to GRO
From: David Miller @ 2009-10-28 10:44 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1256655057.2794.4.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 27 Oct 2009 14:50:57 +0000
> Page buffers containing packets with an incorrect checksum or using a
> protocol not handled by hardware checksum offload were previously not
> passed to LRO. The conversion to GRO changed this, but did not set
> the ip_summed value accordingly.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
> This affects 2.6.31 and seems like a candidate for a stable update.
Queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] cnic: Fix L2CTX_STATUSB_NUM offset in context memory.
From: David Miller @ 2009-10-28 10:42 UTC (permalink / raw)
To: mchan; +Cc: davem, netdev, benli
In-Reply-To: <1256662728-21864-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 27 Oct 2009 08:58:48 -0800
> The BNX2_L2CTX_STATUSB_NUM definition needs to be changed to match
> the recent firmware update:
>
> commit 078b0735881c7969aaf21469f3577831cddd9f8c
> bnx2: Update firmware to 5.0.0.j3.
>
> Without the fix, bnx2 can crash intermittently in bnx2_rx_int() when
> iSCSI is enabled.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: Benjamin Li <benli@broadcom.com>
Applied to net-2.6, but please be explicit about what tree you
want me to apply this to in the future.
Sure I could deduce this by running "git describe" on that
commit ID mentioned in the commit message, but why not be
explicit? :-)
^ 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