Re: [PATCH 2/3] add dev_to_node()
From: Christoph Hellwig <[EMAIL PROTECTED]> Date: Sun, 5 Nov 2006 00:53:23 +0100 > On Sat, Nov 04, 2006 at 06:06:48PM -0500, Dave Jones wrote: > > On Sat, Nov 04, 2006 at 11:56:29PM +0100, Christoph Hellwig wrote: > > > > This will break the compile for !NUMA if someone ends up doing a bisect > > and lands here as a bisect point. > > > > You introduce this nice wrapper.. > > The dev_to_node wrapper is not enough as we can't assign to (-1) for > the non-NUMA case. So I added a second macro, set_dev_node for that. > > The patch below compiles and works on numa and non-NUMA platforms. > > Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> Looks good to me. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take22 0/4] kevent: Generic event handling mechanism.
Hi! On Fri 2006-11-03 12:13:02, Evgeniy Polyakov wrote: > On Fri, Nov 03, 2006 at 09:57:12AM +0100, Pavel Machek ([EMAIL PROTECTED]) > wrote: > > > So, kqueue API and structures can not be usd in Linux. > > > > Not sure what you are smoking, but "there's unsigned long in *bsd > > version, lets rewrite it from scratch" sounds like very bad idea. What > > about fixing that one bit you don't like? > > It is not about what I dislike, but about what is broken or not. > Putting u64 instead of a long or some kind of that _is_ incompatible > already, so why should we even use it? Well.. u64 vs unsigned long *is* binary incompatible, but it is similar enough that it is going to be compatible at source level, or maybe userland app will need *minor* ifdefs... That's better than two completely different versions... > And, btw, what we are talking about? Is it about the whole kevent > compared to kqueue in kernelspace, or just about what structure is being > transferred between kernelspace and userspace? > I'm sure, it was some kind of a joke to 'not rewrite *bsd from scratch > and use kqueue in Linux kernel as is'. No, it is probably not possible to take code from BSD kernel and "just port it". But keeping same/similar userland interface would be nice. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take22 0/4] kevent: Generic event handling mechanism.
On Sun, Nov 05, 2006 at 12:19:33PM +0100, Pavel Machek ([EMAIL PROTECTED])
wrote:
> Hi!
>
> On Fri 2006-11-03 12:13:02, Evgeniy Polyakov wrote:
> > On Fri, Nov 03, 2006 at 09:57:12AM +0100, Pavel Machek ([EMAIL PROTECTED])
> > wrote:
> > > > So, kqueue API and structures can not be usd in Linux.
> > >
> > > Not sure what you are smoking, but "there's unsigned long in *bsd
> > > version, lets rewrite it from scratch" sounds like very bad idea. What
> > > about fixing that one bit you don't like?
> >
> > It is not about what I dislike, but about what is broken or not.
> > Putting u64 instead of a long or some kind of that _is_ incompatible
> > already, so why should we even use it?
>
> Well.. u64 vs unsigned long *is* binary incompatible, but it is
> similar enough that it is going to be compatible at source level, or
> maybe userland app will need *minor* ifdefs... That's better than two
> completely different versions...
>
> > And, btw, what we are talking about? Is it about the whole kevent
> > compared to kqueue in kernelspace, or just about what structure is being
> > transferred between kernelspace and userspace?
> > I'm sure, it was some kind of a joke to 'not rewrite *bsd from scratch
> > and use kqueue in Linux kernel as is'.
>
> No, it is probably not possible to take code from BSD kernel and "just
> port it". But keeping same/similar userland interface would be nice.
It is not only probably, but not even unlikely - it is impossible to get
FreeBSD kqueue code and port it - that port will be completely different
system.
It is impossible to have the same event structure, one should create
#if defined kqueue
fill all members of the structure
#else if defined kevent
fill different members name, since Linux does not even have some types
#endif
*BSD kevent (structure transferred between userspace and kernelspace)
struct kevent {
uintptr_t ident; /* identifier for this event */
short filter;/* filter for event */
u_short flags; /* action flags for kqueue */
u_int fflags;/* filter flag value */
intptr_t data; /* filter data value */
void *udata; /* opaque user data identifier */
};
You must fill all fields differently due to above.
Just an example: Linux kevent has extended ID field which is grouped
into type.event, kqueue has different pointer indent and short filter.
Linux kevent does not have filters, but instead it has generic storages
of events which can be processed in any way origin of the storage wants
(this for example allows to create aio_sendfile() (which is dropped from
patchset currently) which no other system in the wild has).
There are too many differences. It is just different systems.
If both can be described by sentence "system which handles events", it
does not mean that they are the same and can use the structures or even
have similar design.
Kevent is not kqueue in any way (although there are certain
similarities), so they can not share anything.
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[sungem] proposal for a new locking strategy
Hi! Some (long) time ago benh wrote a blaming comment in sungem.c about that driver's locking strategy. That comment basically says that we probably don't need two spinlocks. I agree! Proposal: Today's sungem effectively uses two spinlock's: "lock" and "tx_lock". "tx_lock" is held by the xmit function when sending out a packet. Lots of functions grab "tx_lock" not to mess up with xmit (gem_stop_phy(), gem_change_mtu(), etc.). All of these funcs also take "lock"! What we could do is remove "lx_lock", have the above functions take only "lock", and rely on dev->_xmit_lock to protect the xmit func from reentrance. In that case, obviously, the driver wouldn't feature LLTX anymore. When (re-)configuring we'd now quiesce the device, with the new functions gem_netif_stop() and gem_full_lock(), in the same way as tg3 does. gem_interrupt(), gem_poll(), and gem_start_xmit() could become lockless. Fast! Basically this proposal makes the data path faster, the control path slower, and simplifies the code by using one single spinlock within the driver. If the idea seems reasonable to you guys I can go ahead and cook up something... Thanks, -- Eric - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [sungem] proposal for a new locking strategy
On Sun, 2006-11-05 at 14:00 +0100, Eric Lemoine wrote: > Hi! > > Some (long) time ago benh wrote a blaming comment in sungem.c about > that driver's locking strategy. That comment basically says that we > probably don't need two spinlocks. Yeah :) Note that I mostly blamed myself there ... Just never found the time to sit down a figure out a proper locking. > I agree! > > Proposal: > > Today's sungem effectively uses two spinlock's: "lock" and "tx_lock". > > "tx_lock" is held by the xmit function when sending out a packet. Lots > of functions grab "tx_lock" not to mess up with xmit (gem_stop_phy(), > gem_change_mtu(), etc.). > > All of these funcs also take "lock"! > > What we could do is remove "lx_lock", have the above functions take > only "lock", and rely on dev->_xmit_lock to protect the xmit func from > reentrance. In that case, obviously, the driver wouldn't feature LLTX > anymore. We could probably do even better but yeah, a single lock is a good start. Overall, I'm unhappy with the infrastructure provided by the network stack though. (Might be better nowadays, but last I looked, for example, I couldn't properly do things like stopping MAPI poll from set_multicast etc... due to locks held by the upper level). > When (re-)configuring we'd now quiesce the device, with the new > functions gem_netif_stop() and gem_full_lock(), in the same way as tg3 > does. > > gem_interrupt(), gem_poll(), and gem_start_xmit() could become lockless. Fast! > > Basically this proposal makes the data path faster, the control path > slower, and simplifies the code by using one single spinlock within > the driver. > > If the idea seems reasonable to you guys I can go ahead and cook up > something... I certainly does. Bring on the patch ! :-) Ben. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [sungem] proposal for a new locking strategy
On 11/5/06, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: On Sun, 2006-11-05 at 14:00 +0100, Eric Lemoine wrote: > Hi! > > Some (long) time ago benh wrote a blaming comment in sungem.c about > that driver's locking strategy. That comment basically says that we > probably don't need two spinlocks. Yeah :) Note that I mostly blamed myself there ... Just never found the time to sit down a figure out a proper locking. I actually did introduce tx_lock! So you could well have blamed me :-) > I agree! > > Proposal: > > Today's sungem effectively uses two spinlock's: "lock" and "tx_lock". > > "tx_lock" is held by the xmit function when sending out a packet. Lots > of functions grab "tx_lock" not to mess up with xmit (gem_stop_phy(), > gem_change_mtu(), etc.). > > All of these funcs also take "lock"! > > What we could do is remove "lx_lock", have the above functions take > only "lock", and rely on dev->_xmit_lock to protect the xmit func from > reentrance. In that case, obviously, the driver wouldn't feature LLTX > anymore. We could probably do even better but yeah, a single lock is a good start. Overall, I'm unhappy with the infrastructure provided by the network stack though. (Might be better nowadays, but last I looked, for example, I couldn't properly do things like stopping MAPI poll from set_multicast etc... due to locks held by the upper level). What you said in your comment is that set_multicast and change_mtu cannot schedule() because the upper layer holds a spinlock. This is still the case actually. > When (re-)configuring we'd now quiesce the device, with the new > functions gem_netif_stop() and gem_full_lock(), in the same way as tg3 > does. > > gem_interrupt(), gem_poll(), and gem_start_xmit() could become lockless. Fast! > > Basically this proposal makes the data path faster, the control path > slower, and simplifies the code by using one single spinlock within > the driver. > > If the idea seems reasonable to you guys I can go ahead and cook up something... I certainly does. Bring on the patch ! :-) Will arrange some time to do it. Thanks for your quick response. -- Eric - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC, PATCH] Purging local routes on NETDEV_DOWN event
Hi,
We've noticed that when taking network interface down the local route
for its address is preserved. The following console session
illustrates it:
# ip addr add 5.5.5.5 dev eth4
# ip route list table all | grep eth4
local 5.5.5.5 dev eth4 table 255 vrf 0 proto kernel scope host src 5.5.5.5
# ip link set eth4 down
local 5.5.5.5 dev eth4 table 255 vrf 0 proto kernel scope host src 5.5.5.5
There seems to be an asymmetry between NETDEV_UP and NETDEV_DOWN events
in fib_netdev_event at net/ipv4/fib_frontend.c. On NETDEV_UP we are adding
routes for interface addresses. However on NETDEV_DOWN we do not delete them.
The attached (for a fear of GMail tab munging :)) patch tries to change it.
What do you think?
Thanks,
Boris.
Signed-off-by: Boris Sukholitko ([EMAIL PROTECTED])
---
Index: linux-2.6.18/net/ipv4/fib_frontend.c
===
--- linux-2.6.18.orig/net/ipv4/fib_frontend.c 2006-11-01 18:15:31.0 +0200
+++ linux-2.6.18/net/ipv4/fib_frontend.c 2006-11-05 15:32:56.0 +0200
@@ -727,6 +727,8 @@
*/
for (ifa1 = in_dev->ifa_list; ifa1; ifa1 = ifa1->ifa_next) {
+ if (ifa == ifa1)
+ continue;
if (ifa->ifa_local == ifa1->ifa_local)
ok |= LOCAL_OK;
if (ifa->ifa_broadcast == ifa1->ifa_broadcast)
@@ -880,6 +882,9 @@
rt_cache_flush(-1);
break;
case NETDEV_DOWN:
+ for_ifa(in_dev) {
+ fib_del_ifaddr(ifa);
+ } endfor_ifa(in_dev);
fib_disable_ip(dev, 0);
break;
case NETDEV_CHANGEMTU:
Re: [PATCH 1/1] Net: kconfig, correct traffic shaper
Jiri Slaby wrote: > Ok, thanks for comments. Here it comes, please (n)ack it: > > -- > > kconfig, correct traffic shaper > > As Patrick McHardy <[EMAIL PROTECTED]> suggested, Traffic Shaper is > now obsolete and alternative to it is no longer CBQ, since its problems with > virtual devices, alter Kconfig text to reflect this -- put a link to the > traffic schedulers as a whole. > > Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> > Cc: Alan Cox <[EMAIL PROTECTED]> > Cc: Patrick McHardy <[EMAIL PROTECTED]> Looks good, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] d80211: change the cookie to be opaque
On Friday 03 November 2006 05:15, John W. Linville wrote: > On Fri, Nov 03, 2006 at 01:46:31AM +0100, Johannes Berg wrote: > > > > > Ok, that one was wrong. But what is it doing in the public API? We need > > > to remove it from the public API and leave struct net_device *dev as the > > > parameter. adm8211 actually uses it and increases the tx_fifo_error > > > counter, but that's a bit strange. > > > > Fixed, and since, as always, netdev doesn't like my patches, they're > > here instead: > > > > http://johannes.sipsolutions.net/files/d80211-mdev-cleanup/ > > > > I also added d80211-reduce-mdev.patch which reduces stupid mdev usage, > > but see the description in the patch itself. > > 403 Forbidden (shouldn't that be Verboten? :-) > > FWIW, I have the other 6 patches on the 'pending' branch of > wireless-dev. Driver authors, please proceed accordingly. I am currently working on the fixes for rt2x00, the above patches look very good, and also provide me with a chance to cleanup some garbage in rt2x00. :) I'll make the patches for this part of my patch series which I will send to the netdev list in 1 or 2 weeks. (I cannot do it any sooner due to school and work). Ivo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] d80211: change the cookie to be opaque
On Sun, 2006-11-05 at 16:20 +0100, Ivo van Doorn wrote: > I am currently working on the fixes for rt2x00, the above patches look very > good, > and also provide me with a chance to cleanup some garbage in rt2x00. :) > I'll make the patches for this part of my patch series which I will send to > the netdev > list in 1 or 2 weeks. (I cannot do it any sooner due to school and work). Actually, disregard these patches. I have totally different ones I'm about to post. johannes signature.asc Description: This is a digitally signed message part
[PATCH 0/11] convert d80211 to a proper protocol
Hi, I figured I'd look how hard it actually was to convert d80211 to a proper protocol. And contrary to my own expectations I succeeded in doing that in just over a day. Just like 8021q, it has virtual devices. The patchset is huge and can be found at http://johannes.sipsolutions.net/files/d80211-proto/ John, please apply patches 001 and 002 out of the patchset as soon as you can -- they fix issues with cfg80211 that came up on IRC and in private mail to me. Very important, and not related to converting it to a protocol. Each patch comes with a subject and description but since they're large let me discuss some bits here. 001-cfg80211-fix-Makefile.patch cfg80211: fix Makefile brokenness 002-cfg80211-wext-compat.patch cfg80211: fix WE compat code Absolutely required to fix two issues with cfg80211 that make the current tree usable only in the strange configuration WE_NETLINK on and CFG80211 off. 003-d80211-cookie.patch d80211: change the cookie to be opaque This changes the 'cookie' that d80211 returns from alloc_hw to be an opaque value to the driver. Turned out that it wasn't such a great idea but since it was generally a clean up I kept this patch to base my other patches on. 004-bcm43xx-adjust.patch: bcm43xx: adjust for the d80211 changes This adjusts bcm43xx for above changes with the cookie pointer. 005-d80211-reduce-mdev-1.patch 006-d80211-reduce-mdev-2.patch d80211: reduce mdev usage These two patches reduce mdev madness and change a lot of functions to take a struct ieee80211_local * instead of the master netdev 007-d80211-cleanup-rxmgmt.patch d80211: reduce mdev usage, fix ieee80211_rx_mgmt Cleans up the ieee80211_rx_mgmt and related code 008-d80211-scan-sanity.patch d80211: reduce master ieee80211_ptr deref in scan routines Similar to the reduce mdev patches, just for the scan routines 009-d80211-convert-spaces.patch d80211: convert leading spaces to tabs I hated working on the code, so I did this. The next patch breaks everything anyway. 010-d80211-proto.patch d80211: convert to an 802.11 protocol Converts d80211 to be a protocol together with tons of cleanups and more. Hard to describe in two lines. 011-bcm43xx-adjust-proto.patch bcm43xx: adjust to register a real struct net_device makes bcm43xx function after the previous patch Have fun! johannes signature.asc Description: This is a digitally signed message part
Re: [RFC, PATCH] Purging local routes on NETDEV_DOWN event
* Boris Sukholitko <[EMAIL PROTECTED]> 2006-11-05 16:00 > We've noticed that when taking network interface down the local route > for its address is preserved. The following console session > illustrates it: > > # ip addr add 5.5.5.5 dev eth4 > # ip route list table all | grep eth4 > local 5.5.5.5 dev eth4 table 255 vrf 0 proto kernel scope host src > 5.5.5.5 > # ip link set eth4 down > local 5.5.5.5 dev eth4 table 255 vrf 0 proto kernel scope host src > 5.5.5.5 This example is incomplete and misleading. The local route is managed completely synchroneous with the address itself. See the NETDEV_UP/ NETDEV_DOWN handlers of inetaddr events: case NETDEV_UP: fib_add_ifaddr(ifa); case NETDEV_DOWN: fib_del_ifaddr(ifa); The broadcast routes are added/removed when the interface goes up and down. The fib_addr_ifaddr() in the NETDEV_UP() handler only exists to add broadcast routes for local address which have been added while the interface was down. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/11] convert d80211 to a proper protocol
Hi, > I figured I'd look how hard it actually was to convert d80211 to a > proper protocol. And contrary to my own expectations I succeeded in > doing that in just over a day. Just like 8021q, it has virtual devices. > > The patchset is huge and can be found at > http://johannes.sipsolutions.net/files/d80211-proto/ I have a question regarding the enabling and disabling the radio in this new layout. Previously the open() and stop() methods in ieee80211_hw had been deprecated and the driver should enable or disable the radio based on the add_interface and remove_interface() functions. Now that the driver should provide open() and stop() for the netdevice structure does this mean that these 2 methods are back in control for enabling and disabling the radio? And if so what should the add_interface and remove_interface, should they be only in charge of triggering some configuration changes (like mode and mac address)? Ivo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [sungem] proposal for a new locking strategy
On Sun, 5 Nov 2006 14:17:38 +0100 "Eric Lemoine" <[EMAIL PROTECTED]> wrote: > On 11/5/06, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Sun, 2006-11-05 at 14:00 +0100, Eric Lemoine wrote: > > > Hi! > > > > > > Some (long) time ago benh wrote a blaming comment in sungem.c about > > > that driver's locking strategy. That comment basically says that we > > > probably don't need two spinlocks. > > > > Yeah :) Note that I mostly blamed myself there ... Just never found the > > time to sit down a figure out a proper locking. > > I actually did introduce tx_lock! So you could well have blamed me :-) > > > > > > > I agree! > > > > > > Proposal: > > > > > > Today's sungem effectively uses two spinlock's: "lock" and "tx_lock". > > > > > > "tx_lock" is held by the xmit function when sending out a packet. Lots > > > of functions grab "tx_lock" not to mess up with xmit (gem_stop_phy(), > > > gem_change_mtu(), etc.). > > > > > > All of these funcs also take "lock"! > > > > > > What we could do is remove "lx_lock", have the above functions take > > > only "lock", and rely on dev->_xmit_lock to protect the xmit func from > > > reentrance. In that case, obviously, the driver wouldn't feature LLTX > > > anymore. > > > > We could probably do even better but yeah, a single lock is a good > > start. Overall, I'm unhappy with the infrastructure provided by the > > network stack though. (Might be better nowadays, but last I looked, for > > example, I couldn't properly do things like stopping MAPI poll from > > set_multicast etc... due to locks held by the upper level). > > What you said in your comment is that set_multicast and change_mtu > cannot schedule() because the upper layer holds a spinlock. This is > still the case actually. > > > > > > When (re-)configuring we'd now quiesce the device, with the new > > > functions gem_netif_stop() and gem_full_lock(), in the same way as tg3 > > > does. > > > > > > gem_interrupt(), gem_poll(), and gem_start_xmit() could become lockless. > > > Fast! > > > > > > Basically this proposal makes the data path faster, the control path > > > slower, and simplifies the code by using one single spinlock within > > > the driver. > > > > > > If the idea seems reasonable to you guys I can go ahead and cook up > > > something... > > > > I certainly does. Bring on the patch ! :-) > > Will arrange some time to do it. > > Thanks for your quick response. > > You could also just use net_tx_lock() now. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/11] convert d80211 to a proper protocol
Hi, > Previously the open() and stop() methods in ieee80211_hw had been > deprecated and the driver should enable or disable the radio > based on the add_interface and remove_interface() functions. > Now that the driver should provide open() and stop() for the netdevice > structure does this mean that these 2 methods are back in control > for enabling and disabling the radio? Yeah, it'll have to, otherwise the device it created itself will be totally useless unless some other device is also open. > And if so what should the > add_interface and remove_interface, should they be only in charge of > triggering some configuration changes (like mode and mac address)? Mostly notably it's probably going to be used for the drivers to have veto powers, if they can't handle some specific combinations etc. Though for 802.11h the radio does need to be turned off in some cases regardless of the up/down state, so we'll have to think about that. Or we just force all interfaces down? Not sure yet. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/11] convert d80211 to a proper protocol
Hi, > Previously the open() and stop() methods in ieee80211_hw had been > deprecated and the driver should enable or disable the radio > based on the add_interface and remove_interface() functions. > Now that the driver should provide open() and stop() for the netdevice > structure does this mean that these 2 methods are back in control > for enabling and disabling the radio? Yeah, it'll have to, otherwise the device it created itself will be totally useless unless some other device is also open. > And if so what should the > add_interface and remove_interface, should they be only in charge of > triggering some configuration changes (like mode and mac address)? Mostly notably it's probably going to be used for the drivers to have veto powers, if they can't handle some specific combinations etc. Though for 802.11h the radio does need to be turned off in some cases regardless of the up/down state, so we'll have to think about that. Or we just force all interfaces down? Not sure yet. I confident we can work out these issues if we agree that converting it to a protocol is a good thing. After doing it, I'm personally pretty convinced that it is, some things just fell into place nicely and feel less hacky. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/11] convert d80211 to a proper protocol
On Sun, 2006-11-05 at 18:05 +0100, Johannes Berg wrote: hey, I thought I caught this one before it went out to add the last paragraph :/ sorry. the other one is the intended copy. johannes signature.asc Description: This is a digitally signed message part
Re: [sungem] proposal for a new locking strategy
You could also just use net_tx_lock() now.
You mean netif_tx_lock()?
Thanks for letting me know about that function. Yes, I may need it.
tg3 and bnx2 use it to wake up the transmit queue:
if (unlikely(netif_queue_stopped(tp->dev) &&
(tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH))) {
netif_tx_lock(tp->dev);
if (netif_queue_stopped(tp->dev) &&
(tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH))
netif_wake_queue(tp->dev);
netif_tx_unlock(tp->dev);
}
2.6.17 didn't use it. Was it a bug?
Thanks,
--
Eric
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [sungem] proposal for a new locking strategy
On Sun, 5 Nov 2006 18:28:33 +0100
"Eric Lemoine" <[EMAIL PROTECTED]> wrote:
> > You could also just use net_tx_lock() now.
>
> You mean netif_tx_lock()?
>
> Thanks for letting me know about that function. Yes, I may need it.
> tg3 and bnx2 use it to wake up the transmit queue:
>
> if (unlikely(netif_queue_stopped(tp->dev) &&
> (tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH))) {
> netif_tx_lock(tp->dev);
> if (netif_queue_stopped(tp->dev) &&
> (tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH))
> netif_wake_queue(tp->dev);
> netif_tx_unlock(tp->dev);
> }
>
> 2.6.17 didn't use it. Was it a bug?
>
> Thanks,
No, it was introduced in 2.6.18. The functions are just a wrapper
around the network device transmit lock that is normally held.
If the device does not need to acquire the lock during IRQ, it
is a good alternative and avoids a second lock.
For transmit locking there are three common alternatives:
Method A: dev->queue_xmit_lock and per-device tx_lock
send: dev->xmit_lock held by caller
dev->hard_start_xmit acquires netdev_priv(dev)->tx_lock
irq: netdev_priv(dev)->tx_lock acquired
Method B: dev->queue_xmit_lock only
send: dev->xmit_lock held by caller
irq: schedules softirq (NAPI)
napi_poll: calls netif_tx_lock() which acquires dev->xmit_lock
Method C: LLTX
set dev->features LLTX
send: no locks held by caller
dev->hard_start_xmit acquires netdev_priv(dev)->tx_lock
irq: netdev_priv(dev)->tx_lock acquired
Method A is the only one that works with 2.4 and early (2.6.8?) kernels.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [sungem] proposal for a new locking strategy
On 11/5/06, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
On Sun, 5 Nov 2006 18:28:33 +0100
"Eric Lemoine" <[EMAIL PROTECTED]> wrote:
> > You could also just use net_tx_lock() now.
>
> You mean netif_tx_lock()?
>
> Thanks for letting me know about that function. Yes, I may need it.
> tg3 and bnx2 use it to wake up the transmit queue:
>
> if (unlikely(netif_queue_stopped(tp->dev) &&
> (tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH))) {
> netif_tx_lock(tp->dev);
> if (netif_queue_stopped(tp->dev) &&
> (tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH))
> netif_wake_queue(tp->dev);
> netif_tx_unlock(tp->dev);
> }
>
> 2.6.17 didn't use it. Was it a bug?
>
> Thanks,
No, it was introduced in 2.6.18. The functions are just a wrapper
around the network device transmit lock that is normally held.
If the device does not need to acquire the lock during IRQ, it
is a good alternative and avoids a second lock.
For transmit locking there are three common alternatives:
Method A: dev->queue_xmit_lock and per-device tx_lock
send: dev->xmit_lock held by caller
dev->hard_start_xmit acquires netdev_priv(dev)->tx_lock
irq: netdev_priv(dev)->tx_lock acquired
Method B: dev->queue_xmit_lock only
send: dev->xmit_lock held by caller
irq: schedules softirq (NAPI)
napi_poll: calls netif_tx_lock() which acquires dev->xmit_lock
Method C: LLTX
set dev->features LLTX
send: no locks held by caller
dev->hard_start_xmit acquires netdev_priv(dev)->tx_lock
irq: netdev_priv(dev)->tx_lock acquired
Method A is the only one that works with 2.4 and early (2.6.8?) kernels.
Current sungem does Method C, and uses two locks: lock and tx_lock.
What I was planning to do is Method B (which current tg3 uses). It
seems to me that Method B is better than Method C. What do you think?
--
Eric
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [sungem] proposal for a new locking strategy
On Sun, 5 Nov 2006 18:52:45 +0100
"Eric Lemoine" <[EMAIL PROTECTED]> wrote:
> On 11/5/06, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > On Sun, 5 Nov 2006 18:28:33 +0100
> > "Eric Lemoine" <[EMAIL PROTECTED]> wrote:
> >
> > > > You could also just use net_tx_lock() now.
> > >
> > > You mean netif_tx_lock()?
> > >
> > > Thanks for letting me know about that function. Yes, I may need it.
> > > tg3 and bnx2 use it to wake up the transmit queue:
> > >
> > > if (unlikely(netif_queue_stopped(tp->dev) &&
> > > (tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH))) {
> > > netif_tx_lock(tp->dev);
> > > if (netif_queue_stopped(tp->dev) &&
> > > (tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH))
> > > netif_wake_queue(tp->dev);
> > > netif_tx_unlock(tp->dev);
> > > }
> > >
> > > 2.6.17 didn't use it. Was it a bug?
> > >
> > > Thanks,
> >
> > No, it was introduced in 2.6.18. The functions are just a wrapper
> > around the network device transmit lock that is normally held.
> >
> > If the device does not need to acquire the lock during IRQ, it
> > is a good alternative and avoids a second lock.
> >
> > For transmit locking there are three common alternatives:
> >
> > Method A: dev->queue_xmit_lock and per-device tx_lock
> > send: dev->xmit_lock held by caller
> > dev->hard_start_xmit acquires netdev_priv(dev)->tx_lock
> >
> > irq: netdev_priv(dev)->tx_lock acquired
> >
> > Method B: dev->queue_xmit_lock only
> > send: dev->xmit_lock held by caller
> > irq: schedules softirq (NAPI)
> > napi_poll: calls netif_tx_lock() which acquires dev->xmit_lock
> >
> > Method C: LLTX
> > set dev->features LLTX
> > send: no locks held by caller
> > dev->hard_start_xmit acquires netdev_priv(dev)->tx_lock
> > irq: netdev_priv(dev)->tx_lock acquired
> >
> > Method A is the only one that works with 2.4 and early (2.6.8?) kernels.
> >
>
> Current sungem does Method C, and uses two locks: lock and tx_lock.
> What I was planning to do is Method B (which current tg3 uses). It
> seems to me that Method B is better than Method C. What do you think?
B is better than C because the transmit logic doesn't have to
spin in the case of lock contention, but it is not a big difference.
You can only use B if you do Tx completion outside of hard IRQ.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-2.6.19-rc4-g10b1fbdb build #114 failed
On Sunday 05 November 2006 1:43 pm, Toralf Förster wrote: > Hello, > > the build with the attached .config failed, make ends with: > ... > > : undefined reference to `cipso_v4_sock_getattr' Hmm, that's both strange and not good :( I'm grabbing Linus' latests bits and I'll see what I can do. -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [sungem] proposal for a new locking strategy
On 11/5/06, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
On Sun, 5 Nov 2006 18:52:45 +0100
"Eric Lemoine" <[EMAIL PROTECTED]> wrote:
> On 11/5/06, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > On Sun, 5 Nov 2006 18:28:33 +0100
> > "Eric Lemoine" <[EMAIL PROTECTED]> wrote:
> >
> > > > You could also just use net_tx_lock() now.
> > >
> > > You mean netif_tx_lock()?
> > >
> > > Thanks for letting me know about that function. Yes, I may need it.
> > > tg3 and bnx2 use it to wake up the transmit queue:
> > >
> > > if (unlikely(netif_queue_stopped(tp->dev) &&
> > > (tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH))) {
> > > netif_tx_lock(tp->dev);
> > > if (netif_queue_stopped(tp->dev) &&
> > > (tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH))
> > > netif_wake_queue(tp->dev);
> > > netif_tx_unlock(tp->dev);
> > > }
> > >
> > > 2.6.17 didn't use it. Was it a bug?
> > >
> > > Thanks,
> >
> > No, it was introduced in 2.6.18. The functions are just a wrapper
> > around the network device transmit lock that is normally held.
> >
> > If the device does not need to acquire the lock during IRQ, it
> > is a good alternative and avoids a second lock.
> >
> > For transmit locking there are three common alternatives:
> >
> > Method A: dev->queue_xmit_lock and per-device tx_lock
> > send: dev->xmit_lock held by caller
> > dev->hard_start_xmit acquires netdev_priv(dev)->tx_lock
> >
> > irq: netdev_priv(dev)->tx_lock acquired
> >
> > Method B: dev->queue_xmit_lock only
> > send: dev->xmit_lock held by caller
> > irq: schedules softirq (NAPI)
> > napi_poll: calls netif_tx_lock() which acquires dev->xmit_lock
> >
> > Method C: LLTX
> > set dev->features LLTX
> > send: no locks held by caller
> > dev->hard_start_xmit acquires netdev_priv(dev)->tx_lock
> > irq: netdev_priv(dev)->tx_lock acquired
> >
> > Method A is the only one that works with 2.4 and early (2.6.8?) kernels.
> >
>
> Current sungem does Method C, and uses two locks: lock and tx_lock.
> What I was planning to do is Method B (which current tg3 uses). It
> seems to me that Method B is better than Method C. What do you think?
B is better than C because the transmit logic doesn't have to
spin in the case of lock contention, but it is not a big difference.
Current sungem does C but uses try_lock() to acquire its private
tx_lock. So it doesn't spin either in case of contention.
You can only use B if you do Tx completion outside of hard IRQ.
Because qdisk_restart() is called with bh disabled *but* with irq
enabled, right?
--
Eric
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 and region #2 not an MMIO resource
Dne středa 01 listopad 2006 23:13 Francois Romieu napsal(a): > Francois Romieu <[EMAIL PROTECTED]> : > [...] > > > Please send lspci -vvx, I need the hexadecimal ID. > > Actually, no. This is a 8167, 2.6.19-rc4 includes the correct code for it. thanks, it worked but udev named it also eth0, even there already was eth0 in persistent rules, so i was without connection after remote restart of computer cu libor pgpPEZgzHi3tI.pgp Description: PGP signature
Re: linux-2.6.19-rc4-g10b1fbdb build #114 failed
On Sun, 5 Nov 2006, Toralf F?rster wrote: Hello, the build with the attached .config failed, make ends with: ... : undefined reference to `cipso_v4_sock_getattr' net/built-in.o: In function `netlbl_socket_getattr': Ah ha! Why did you have to go and build a kernel without TCP/IP networking ;) It looks like I was stupid and made NetLabel depend on CONFIG_NET and not CONFIG_INET, the patch below should fix this by making NetLabel depend on CONFIG_INET and CONFIG_SECURITY. Please review and apply for 2.6.19. Signed-off-by: Paul Moore <[EMAIL PROTECTED]> diff --git a/net/Kconfig b/net/Kconfig index a81aca4..67e39ad 100644 --- a/net/Kconfig +++ b/net/Kconfig @@ -63,6 +63,7 @@ config INET if INET source "net/ipv4/Kconfig" source "net/ipv6/Kconfig" +source "net/netlabel/Kconfig" endif # if INET @@ -249,8 +250,6 @@ source "net/ieee80211/Kconfig" config WIRELESS_EXT bool -source "net/netlabel/Kconfig" - config FIB_RULES bool diff --git a/net/netlabel/Kconfig b/net/netlabel/Kconfig index 9f7121a..56958c8 100644 --- a/net/netlabel/Kconfig +++ b/net/netlabel/Kconfig @@ -4,7 +4,7 @@ # config NETLABEL bool "NetLabel subsystem support" - depends on NET && SECURITY + depends on SECURITY default n ---help--- NetLabel provides support for explicit network packet labeling -- paul moore linux security @ hp
Re: [RFC, PATCH] Purging local routes on NETDEV_DOWN event
From: "Boris Sukholitko" <[EMAIL PROTECTED]> Date: Sun, 5 Nov 2006 16:00:20 +0200 > We've noticed that when taking network interface down the local route > for its address is preserved. This behavior is intentional. IP addresses are associated with the system, not a particular network interface. So if you want the IP and it's local subnet route to go away, you must explicitly delete that IP address from the interface, just downing the interface is not sufficient. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bcm43xx: Drain TX status before starting IRQs
From: Michael Buesch <[EMAIL PROTECTED]>
Drain the Microcode TX-status-FIFO before we enable IRQs.
This is required, because the FIFO may still have entries left
from a previous run. Those would immediately fire after enabling
IRQs and would lead to an oops in the DMA TXstatus handling code.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: linux-2.6.18/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.18.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6.18/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1463,6 +1463,23 @@ static void handle_irq_transmit_status(s
}
}
+static void drain_txstatus_queue(struct bcm43xx_private *bcm)
+{
+ u32 dummy;
+
+ if (bcm->current_core->rev < 5)
+ return;
+ /* Read all entries from the microcode TXstatus FIFO
+* and throw them away.
+*/
+ while (1) {
+ dummy = bcm43xx_read32(bcm, BCM43xx_MMIO_XMITSTAT_0);
+ if (!dummy)
+ break;
+ dummy = bcm43xx_read32(bcm, BCM43xx_MMIO_XMITSTAT_1);
+ }
+}
+
static void bcm43xx_generate_noise_sample(struct bcm43xx_private *bcm)
{
bcm43xx_shm_write16(bcm, BCM43xx_SHM_SHARED, 0x408, 0x7F7F);
@@ -3517,6 +3534,7 @@ int bcm43xx_select_wireless_core(struct
bcm43xx_macfilter_clear(bcm, BCM43xx_MACFILTER_ASSOC);
bcm43xx_macfilter_set(bcm, BCM43xx_MACFILTER_SELF, (u8
*)(bcm->net_dev->dev_addr));
bcm43xx_security_init(bcm);
+ drain_txstatus_queue(bcm);
ieee80211softmac_start(bcm->net_dev);
/* Let's go! Be careful after enabling the IRQs.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/02 V3] net/ipv6: seperate sit driver to extra module
Joerg Roedel wrote:
> On Sat, Oct 14, 2006 at 01:09:39AM +0200, Jan Dittmer wrote:
>
>>Btw. is there any way to autoload the sit module or is this the
>>task of the distribution tools? Debian etch at least does not
>>automatically probe the module when trying to bring up a 6to4 tunnel.
>
>
> AFAIK there is no way to automatically load the driver from the kernel
> space. The configuration of the tunnel devices requires the sit0 device.
> But this device is installed by the sit driver. I mailed a bug report to
> the Debian people and informed them about the change.
It would be nice to keep things working even with this built as a
module, it took me some time to realize my IPv6 tunnel was broken
because of the missing sit module. This module alias fixes things
until distributions have added an appropriate alias to modprobe.conf.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index b481a4d..be699f8 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -854,3 +854,4 @@ int __init sit_init(void)
module_init(sit_init);
module_exit(sit_cleanup);
MODULE_LICENSE("GPL");
+MODULE_ALIAS("sit0");
Re: [PATCH 01/02 V3] net/ipv6: seperate sit driver to extra module
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Sun, 05 Nov 2006 23:35:07 +0100 > It would be nice to keep things working even with this built as a > module, it took me some time to realize my IPv6 tunnel was broken > because of the missing sit module. This module alias fixes things > until distributions have added an appropriate alias to modprobe.conf. > > Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Would you like me to apply this or is this a temp workaround for folks? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/02 V3] net/ipv6: seperate sit driver to extra module
David Miller wrote: > Would you like me to apply this or is this a temp workaround > for folks? Please apply it. I usually build things as module if possible, which in this case caused my tunnel to break. This will probably happen to others as well. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/02 V3] net/ipv6: seperate sit driver to extra module
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Mon, 06 Nov 2006 00:38:14 +0100 > David Miller wrote: > > Would you like me to apply this or is this a temp workaround > > for folks? > > Please apply it. I usually build things as module if possible, > which in this case caused my tunnel to break. This will > probably happen to others as well. Ok, done. Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-2.6.19-rc4-g10b1fbdb build #114 failed
From: Paul Moore <[EMAIL PROTECTED]> Date: Sun, 5 Nov 2006 16:24:07 -0500 (EST) > On Sun, 5 Nov 2006, Toralf Förster wrote: > > > > Hello, > > > > the build with the attached .config failed, make ends with: > > ... > > : undefined reference to `cipso_v4_sock_getattr' > > net/built-in.o: In function `netlbl_socket_getattr': > > Ah ha! Why did you have to go and build a kernel without TCP/IP > networking ;) > > It looks like I was stupid and made NetLabel depend on CONFIG_NET and not > CONFIG_INET, the patch below should fix this by making NetLabel depend on > CONFIG_INET and CONFIG_SECURITY. Please review and apply for 2.6.19. > > Signed-off-by: Paul Moore <[EMAIL PROTECTED]> Applied, thanks Paul. What email client are you using? There were a bunch of spacing issues I had to correct in your patch before it would apply cleanly. (1) lines with only spaces were changed to empty lines (2) Severl lines had an extra space added to the beginning. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] s2io ppc64 fix for readq/writeq
The s2io driver is redefining it's own readq/writeq based on
readl/writel when the platform doesn't provide native ones. However, it
currently does so by testing #ifndef readq. While that works for now, we
are about to change ppc64 to use inline functions rather that macros for
all those IO accessors which will break that test. This fixes it. I
don't have anything less ugly at hand unfortunately.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
The patch changing ppc64 own definition is scheduled to go in 2.6.20 when
the merge window opens, so it would be nice if this patch could go in a
similar timeframe, provided that you agree with it of course. It can go
earlier as it won't break current ppc64.
Index: linux-cell/drivers/net/s2io.h
===
--- linux-cell.orig/drivers/net/s2io.h 2006-10-13 17:23:49.0 +1000
+++ linux-cell/drivers/net/s2io.h 2006-11-06 13:19:32.0 +1100
@@ -862,8 +862,10 @@ struct s2io_nic {
#define RESET_ERROR 1;
#define CMD_ERROR 2;
-/* OS related system calls */
-#ifndef readq
+/* OS related system calls. Note that ppc64 has readq defined as
+ * an inline, not a macro
+ */
+#if !defined(CONFIG_PPC64) && !defined(readq)
static inline u64 readq(void __iomem *addr)
{
u64 ret = 0;
@@ -875,7 +877,7 @@ static inline u64 readq(void __iomem *ad
}
#endif
-#ifndef writeq
+#if !defined(CONFIG_PPC64) && !defined(writeq)
static inline void writeq(u64 val, void __iomem *addr)
{
writel((u32) (val), addr);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-2.6.19-rc4-g10b1fbdb build #114 failed
On Sunday 05 November 2006 7:45 pm, David Miller wrote: > From: Paul Moore <[EMAIL PROTECTED]> > Date: Sun, 5 Nov 2006 16:24:07 -0500 (EST) > > > On Sun, 5 Nov 2006, Toralf Förster wrote: > > > Hello, > > > > > > the build with the attached .config failed, make ends with: > > > ... > > > > > > : undefined reference to `cipso_v4_sock_getattr' > > > > > > net/built-in.o: In function `netlbl_socket_getattr': > > > > Ah ha! Why did you have to go and build a kernel without TCP/IP > > networking ;) > > > > It looks like I was stupid and made NetLabel depend on CONFIG_NET and not > > CONFIG_INET, the patch below should fix this by making NetLabel depend on > > CONFIG_INET and CONFIG_SECURITY. Please review and apply for 2.6.19. > > > > Signed-off-by: Paul Moore <[EMAIL PROTECTED]> > > Applied, thanks Paul. > > What email client are you using? There were a bunch of spacing > issues I had to correct in your patch before it would apply > cleanly. (1) lines with only spaces were changed to empty lines > (2) Severl lines had an extra space added to the beginning. Sorry about that, that particular mail was sent with pine (I'm at home right now and not at my work machine), usually I use quilt to send my patches out. I checked it briefly in pine to make sure the tabs didn't get converted into spaces but I guess I didn't check well enough. -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ZONE_NORMAL memory exhausted by 4000 TCP sockets
Zhao Xiaoming a écrit : Dears, I'm running a linux box with kernel version 2.6.16. The hardware has 2 Woodcrest Xeon CPUs (2 cores each) and 4G RAM. The NIC cards is Intel 82571 on PCI-e bus. The box is acting as ethernet bridge between 2 Gigabit Ethernets. By configuring ebtables and iptables, an application is running as TCP proxy which will intercept all TCP connections requests from the network and setup another TCP connection to the acture server. The TCP proxy then relays all traffics in both directions. The problem is the memory. Since the box must support thousands of concurrent connections, I know the memory size of ZONE_NORMAL would be a bottleneck as TCP packets would need many buffers. After setting upper limit of net.ipv4.tcp_rmem and net.ipv4.tcp_wmem to 32K bytes, our test began. My test scenario employs 2000 concurrent downloading connections to a IIS server's port 80. The throughput is about 500~600 Mbps which is limited by the capability of the client application. Because all traffics are from server to client and the capability of client machine is bottleneck, I believe the receiver side of the sockets connected with server and the sender side of the sockets connected with client should be filled with packets in correspondent windows. Thus, roughly there should be about 32K * 2000+ 32K*2000 = 128M bytes memory occupied by TCP/IP stack for packet buffering. Data from slabtop confermed it. it's about 140M bytes memory cost after I start the traffic. That reasonablly matched with my estimation. However, /proc/meminfo had a different story. The 'LowFree' dropped from about 710M to 80M. In other words, there's addtional 500M memory in ZONE_NORMAL allocated by someone other than the slab. Why? We dont know. You might post some data so that we can have some ideas. Also, these kind of question is better handled by linux netdev mailing list, so I added a CC to this list. cat /proc/slabinfo cat /proc/meminfo cat /proc/net/sockstat cat /proc/buddyinfo I also made another test that the upper limit of tcp_rmem and tcp_wmem being set to 64K. After 2000 connections transfering a lot of data for several seconds, the linux box showed some error messages such as error allocating memory pages, etc. and became unstable. My questions are: 1. To calculate memory request of TCP sockets, is there any other large amount of memory requested besides send and receive buffer? 2. Is there any logics that emploied by TCP/IP stack that will dynamically allocating memory pages directly instead of from slab? TCP stack is one thing, but other things may consume ram on your kernel. Also, kernel memory allocation might use twice the ram you intend to use because of power of two alignments. Are you using iptables connection tracking ? If you plan to use a lot of RAM in kernel, why dont you use a 64 bits kernel, so that all ram is available for kernel, not only 900 MB ? Eric - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] s2io ppc64 fix for readq/writeq
Benjamin Herrenschmidt wrote:
The s2io driver is redefining it's own readq/writeq based on
readl/writel when the platform doesn't provide native ones. However, it
currently does so by testing #ifndef readq. While that works for now, we
are about to change ppc64 to use inline functions rather that macros for
all those IO accessors which will break that test. This fixes it. I
don't have anything less ugly at hand unfortunately.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
The patch changing ppc64 own definition is scheduled to go in 2.6.20 when
the merge window opens, so it would be nice if this patch could go in a
similar timeframe, provided that you agree with it of course. It can go
earlier as it won't break current ppc64.
Index: linux-cell/drivers/net/s2io.h
===
--- linux-cell.orig/drivers/net/s2io.h 2006-10-13 17:23:49.0 +1000
+++ linux-cell/drivers/net/s2io.h 2006-11-06 13:19:32.0 +1100
@@ -862,8 +862,10 @@ struct s2io_nic {
#define RESET_ERROR 1;
#define CMD_ERROR 2;
-/* OS related system calls */
-#ifndef readq
+/* OS related system calls. Note that ppc64 has readq defined as
+ * an inline, not a macro
+ */
+#if !defined(CONFIG_PPC64) && !defined(readq)
static inline u64 readq(void __iomem *addr)
{
u64 ret = 0;
@@ -875,7 +877,7 @@ static inline u64 readq(void __iomem *ad
}
#endif
-#ifndef writeq
+#if !defined(CONFIG_PPC64) && !defined(writeq)
static inline void writeq(u64 val, void __iomem *addr)
This seems a bit ugly. Could you add
#define readq readq
to your platform instead?
I generally think it's a bug in the kernel-wide API, if use of said API
requires arch-specific ifdefs.
Or maybe the problem could be solved another way, by guaranteeing that a
"good enough for drivers" readq() and writeq() exist on all platforms,
even 32-bit platforms where the operation isn't inherently atomic.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'upstream-fixes' branch of wireless-2.6.git
John W. Linville wrote: I've got the right URL this time... :-) --- The following changes since commit 16b7b2ac0148e839da86af8747b6fa4aad43a9b7: Atsushi Nemoto: [MIPS] Fixup migration to GENERIC_TIME are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-fixes pulled - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Kconfig: remove redundant NETDEVICES depends
applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Net: kconfig, correct traffic shaper
Jiri Slaby wrote: Patrick McHardy <[EMAIL PROTECTED]> wrote: While you're at it .. CBQ is actually not a very good alternative since it doesn't work properly on top of virtual network devices. The closest match for an alternative would be TBF, but HTB and HFSC also do fine. Maybe just point to the traffic schedulers in general. I think you could also change EXPERIMENTAL to OBSOLETE for the shaper device, the traffic schedulers are a lot more flexible. Ok, thanks for comments. Here it comes, please (n)ack it: -- kconfig, correct traffic shaper As Patrick McHardy <[EMAIL PROTECTED]> suggested, Traffic Shaper is now obsolete and alternative to it is no longer CBQ, since its problems with virtual devices, alter Kconfig text to reflect this -- put a link to the traffic schedulers as a whole. Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> Cc: Alan Cox <[EMAIL PROTECTED]> Cc: Patrick McHardy <[EMAIL PROTECTED]> ACK from me, though I think that since it relates to traffic schedulers I think this patch should be merged through DaveM... Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.19-rc4 1/3] ehea: Nullpointer dereferencation fix
applied 1-3 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
