Netdev List
 help / color / mirror / Atom feed
* Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4
From: Herbert Xu @ 2005-05-27  0:11 UTC (permalink / raw)
  To: Ganesh Venkatesan
  Cc: Venkatesan, Ganesh, Andrew Morton, Jian Jun He, anton, rende,
	Brandeburg, Jesse, jgarzik, wangjs, Ronciak, John, cdlwangl,
	linuxppc64-dev, netdev
In-Reply-To: <5fc59ff30505261608541b74fb@mail.gmail.com>

On Thu, May 26, 2005 at 04:08:17PM -0700, Ganesh Venkatesan wrote:
> 
> I do not get it. Bear with my ignorance.
> 
> e100_tx_timeout does not call e100_down. 
> 
> It is called from e100_tx_timeout_task which is invoked as a result of
> schedule_work. Are you saying that it would still not have the right
> context to call netif_disable_poll()?

Sorry, I was not aware that you've already added the sched work
in the driver.  With that it should work correctly.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4
From: Herbert Xu @ 2005-05-27  0:20 UTC (permalink / raw)
  To: Ganesh Venkatesan
  Cc: Venkatesan, Ganesh, Andrew Morton, Jian Jun He, anton, rende,
	Brandeburg, Jesse, jgarzik, wangjs, Ronciak, John, cdlwangl,
	linuxppc64-dev, netdev
In-Reply-To: <20050527001123.GA16594@gondor.apana.org.au>

On Fri, May 27, 2005 at 10:11:23AM +1000, herbert wrote:
> 
> Sorry, I was not aware that you've already added the sched work
> in the driver.  With that it should work correctly.

BTW, I was just checking out your sched work code.  There needs
to be synchronisation between the tx_timeout task and the stop
method.  Otherwise they can race against each other or worse
tx_timeout could keep running even after stop has finished.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* RE: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4
From: Venkatesan, Ganesh @ 2005-05-27  0:28 UTC (permalink / raw)
  To: Herbert Xu, Ganesh Venkatesan
  Cc: Andrew Morton, Jian Jun He, anton, rende, Brandeburg, Jesse,
	jgarzik, wangjs, Ronciak, John, cdlwangl, linuxppc64-dev, netdev

Would adding flush_sheduled_tasks() to e100_down, do it?

Ganesh.

>-----Original Message-----
>From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
>Sent: Thursday, May 26, 2005 5:21 PM
>To: Ganesh Venkatesan
>Cc: Venkatesan, Ganesh; Andrew Morton; Jian Jun He; anton@samba.org;
>rende@cn.ibm.com; Brandeburg, Jesse; jgarzik@pobox.com;
wangjs@cn.ibm.com;
>Ronciak, John; cdlwangl@cn.ibm.com; linuxppc64-
>dev@lists.linuxppc.org.sgi.com; netdev@oss.sgi.com
>Subject: Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while
running
>rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4
>
>On Fri, May 27, 2005 at 10:11:23AM +1000, herbert wrote:
>>
>> Sorry, I was not aware that you've already added the sched work
>> in the driver.  With that it should work correctly.
>
>BTW, I was just checking out your sched work code.  There needs
>to be synchronisation between the tx_timeout task and the stop
>method.  Otherwise they can race against each other or worse
>tx_timeout could keep running even after stop has finished.
>
>Cheers,
>--
>Visit Openswan at http://www.openswan.org/
>Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
>Home Page: http://gondor.apana.org.au/~herbert/
>PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* Re: [NET] 2.6.x build warning
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-05-27  0:54 UTC (permalink / raw)
  To: davem, jgarzik; +Cc: netdev, yoshfuji
In-Reply-To: <42961EDB.7000407@pobox.com>

In article <42961EDB.7000407@pobox.com> (at Thu, 26 May 2005 15:09:15 -0400), Jeff Garzik <jgarzik@pobox.com> says:

> from current git tree:
> 
> net/ipv6/ip6_flowlabel.c: In function `ipv6_flowlabel_opt':
> net/ipv6/ip6_flowlabel.c:540: warning: ignoring return value of 
> `copy_to_user', declared with attribute warn_unused_result

As before, it is intentional.
Okay, let's just waste the result for avoiding the warning.

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

Index: net/ipv6/ip6_flowlabel.c
===================================================================
--- 30b3bda5e47d088b46ab8eab4d69d059a71197e1/net/ipv6/ip6_flowlabel.c  (mode:100644)
+++ uncommitted/net/ipv6/ip6_flowlabel.c  (mode:100644)
@@ -535,10 +535,11 @@
 		if (err)
 			goto done;
 
-		/* Do not check for fault */
-		if (!freq.flr_label)
-			copy_to_user(&((struct in6_flowlabel_req __user *) optval)->flr_label,
-				     &fl->label, sizeof(fl->label));
+		if (!freq.flr_label) {
+			/* Do not check for fault */
+			int dummy = copy_to_user(&((struct in6_flowlabel_req __user *) optval)->flr_label,
+						 &fl->label, sizeof(fl->label));
+		}
 
 		sfl1->fl = fl;
 		sfl1->next = np->ipv6_fl_list;

-- 
YOSHIFUJI Hideaki @ USAGI Project  <yoshfuji@linux-ipv6.org>
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

^ permalink raw reply

* RE: NAPI packet weighting patch
From: Ronciak, John @ 2005-05-27  1:05 UTC (permalink / raw)
  To: Williams, Mitch A, netdev; +Cc: Venkatesan, Ganesh, Brandeburg, Jesse

Are the systems that don't see any difference slower (older?) machines?
I'm wondering what could be the cause of this.  It seems like it should
always work.  I think we need to figure out why there is no difference
on some systems.

Just my 2 cents.

Cheers,
John


> -----Original Message-----
> From: Mitch Williams [mailto:mitch.a.williams@intel.com] 
> Sent: Thursday, May 26, 2005 2:36 PM
> To: netdev@oss.sgi.com
> Cc: Ronciak, John; Venkatesan, Ganesh; Brandeburg, Jesse
> Subject: RFC: NAPI packet weighting patch 
> 
> 
> The following patch (which applies to 2.6.12rc4) adds a new sysctl
> parameter called 'netdev_packet_weight'.  This parameter 
> controls how many
> backlog work units each RX packet is worth.
> 
> With the parameter set to 0 (the default), NAPI polling works 
> exactly as
> it does today:  each packet is worth one backlog work unit, and the
> maximum number of received packets that will be processed in any given
> softirq is controlled by the 'netdev_max_backlog' parameter.
> 
> By setting the netdev_packet_weight to a nonzero value, we make each
> packet worth more than one backlog work unit.  Since it's a 
> shift value, a
> setting of 1 makes each packet worth 2 work units, a setting 
> of 2 makes
> each packet worth 4 units, etc.  Under normal circumstances you would
> never use a value higher than 3, though 4 might work for 
> Gigabit and 10
> Gigabit networks.
> 
> By increasing the packet weight, we accomplish two things:  first, we
> cause the individual NAPI RX loops in each driver to process fewer
> packets.  This means that they will free up RX resources to 
> the hardware
> more often, which reduces the possibility of dropped packets. 
>  Second, it
> shortens the total time spent in the NAPI softirq, which can 
> free the CPU
> to handle other tasks more often, thus reducing overall latency.
> 
> Performance tests in our lab have shown that tweaking this parameter,
> along with the netdev_max_backlog parameter, can provide significant
> performance increase -- greater than 100Mbps improvement -- 
> over default
> settings.  I tested with both e1000 and tg3 drivers and saw 
> improvement in
> both cases.  I did not see higher CPU utilization, even with 
> the increased
> throughput.
> 
> The caveat, of course, is that different systems and network
> configurations require different settings.  On the other hand, that's
> really no different than what we see with the max_backlog 
> parameter today.
> On some systems neither parameter makes any difference.
> 
> Still, we feel that there is value to having this in the 
> kernel.  Please
> test and comment as you have time available.
> 
> Thanks!
> -Mitch Williams
> mitch.a.williams@intel.com
> 
> 
> 
> 
> diff -urpN -x dontdiff 
> rc4-clean/Documentation/filesystems/proc.txt 
> linux-2.6.12-rc4/Documentation/filesystems/proc.txt
> --- rc4-clean/Documentation/filesystems/proc.txt	
> 2005-05-18 16:35:43.000000000 -0700
> +++ linux-2.6.12-rc4/Documentation/filesystems/proc.txt	
> 2005-05-19 11:16:10.000000000 -0700
> @@ -1378,7 +1378,13 @@ netdev_max_backlog
>  ------------------
> 
>  Maximum number  of  packets,  queued  on  the  INPUT  side, 
> when the interface
> -receives packets faster than kernel can process them.
> +receives packets faster than kernel can process them.  This 
> is also the
> +maximum number of packets handled in a single softirq under NAPI.
> +
> +netdev_packet_weight
> +--------------------
> +The value, in netdev_max_backlog unit, of each received 
> packet.  This is a
> +shift value, and should be set no higher than 3.
> 
>  optmem_max
>  ----------
> diff -urpN -x dontdiff rc4-clean/include/linux/sysctl.h 
> linux-2.6.12-rc4/include/linux/sysctl.h
> --- rc4-clean/include/linux/sysctl.h	2005-05-18 
> 16:36:06.000000000 -0700
> +++ linux-2.6.12-rc4/include/linux/sysctl.h	2005-05-18 
> 16:44:07.000000000 -0700
> @@ -242,6 +242,7 @@ enum
>  	NET_CORE_MOD_CONG=16,
>  	NET_CORE_DEV_WEIGHT=17,
>  	NET_CORE_SOMAXCONN=18,
> +	NET_CORE_PACKET_WEIGHT=19,
>  };
> 
>  /* /proc/sys/net/ethernet */
> diff -urpN -x dontdiff rc4-clean/net/core/dev.c 
> linux-2.6.12-rc4/net/core/dev.c
> --- rc4-clean/net/core/dev.c	2005-05-18 16:36:07.000000000 -0700
> +++ linux-2.6.12-rc4/net/core/dev.c	2005-05-19 
> 11:16:57.000000000 -0700
> @@ -1352,6 +1352,7 @@ out:
>    
> ==============================================================
> =========*/
> 
>  int netdev_max_backlog = 300;
> +int netdev_packet_weight = 0; /* each packet is worth 1 
> backlog unit */
>  int weight_p = 64;            /* old backlog weight */
>  /* These numbers are selected based on intuition and some
>   * experimentatiom, if you have more scientific way of doing this
> @@ -1778,6 +1779,7 @@ static void net_rx_action(struct softirq
>  	struct softnet_data *queue = &__get_cpu_var(softnet_data);
>  	unsigned long start_time = jiffies;
>  	int budget = netdev_max_backlog;
> +	int budget_temp;
> 
> 
>  	local_irq_disable();
> @@ -1793,21 +1795,22 @@ static void net_rx_action(struct softirq
>  		dev = list_entry(queue->poll_list.next,
>  				 struct net_device, poll_list);
>  		netpoll_poll_lock(dev);
> -
> -		if (dev->quota <= 0 || dev->poll(dev, &budget)) {
> +		budget_temp = budget;
> +		if (dev->quota <= 0 || dev->poll(dev, &budget_temp)) {
>  			netpoll_poll_unlock(dev);
>  			local_irq_disable();
>  			list_del(&dev->poll_list);
>  			list_add_tail(&dev->poll_list, 
> &queue->poll_list);
>  			if (dev->quota < 0)
> -				dev->quota += dev->weight;
> +				dev->quota += dev->weight >> 
> netdev_packet_weight;
>  			else
> -				dev->quota = dev->weight;
> +				dev->quota = dev->weight >> 
> netdev_packet_weight;
>  		} else {
>  			netpoll_poll_unlock(dev);
>  			dev_put(dev);
>  			local_irq_disable();
>  		}
> +		budget -= (budget - budget_temp) << 
> netdev_packet_weight;
>  	}
>  out:
>  	local_irq_enable();
> diff -urpN -x dontdiff rc4-clean/net/core/sysctl_net_core.c 
> linux-2.6.12-rc4/net/core/sysctl_net_core.c
> --- rc4-clean/net/core/sysctl_net_core.c	2005-03-01 
> 23:38:03.000000000 -0800
> +++ linux-2.6.12-rc4/net/core/sysctl_net_core.c	
> 2005-05-18 16:44:09.000000000 -0700
> @@ -13,6 +13,7 @@
>  #ifdef CONFIG_SYSCTL
> 
>  extern int netdev_max_backlog;
> +extern int netdev_packet_weight;
>  extern int weight_p;
>  extern int no_cong_thresh;
>  extern int no_cong;
> @@ -91,6 +92,14 @@ ctl_table core_table[] = {
>  		.proc_handler	= &proc_dointvec
>  	},
>  	{
> +		.ctl_name	= NET_CORE_PACKET_WEIGHT,
> +		.procname	= "netdev_packet_weight",
> +		.data		= &netdev_packet_weight,
> +		.maxlen		= sizeof(int),
> +		.mode		= 0644,
> +		.proc_handler	= &proc_dointvec
> +	},
> +	{
>  		.ctl_name	= NET_CORE_MAX_BACKLOG,
>  		.procname	= "netdev_max_backlog",
>  		.data		= &netdev_max_backlog,
> 

^ permalink raw reply

* Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4
From: Herbert Xu @ 2005-05-27  1:26 UTC (permalink / raw)
  To: Venkatesan, Ganesh
  Cc: Ganesh Venkatesan, Andrew Morton, Jian Jun He, anton, rende,
	Brandeburg, Jesse, jgarzik, wangjs, Ronciak, John, cdlwangl,
	linuxppc64-dev, netdev
In-Reply-To: <468F3FDA28AA87429AD807992E22D07E056F70D4@orsmsx408>

On Thu, May 26, 2005 at 05:28:55PM -0700, Venkatesan, Ganesh wrote:
> Would adding flush_sheduled_tasks() to e100_down, do it?

Even though it might be OK it's probably not a good idea to have
the task flush itself while it's running.

If you put it in the e100_close function then it should be fine.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4
From: Andrew Morton @ 2005-05-27  1:44 UTC (permalink / raw)
  To: Herbert Xu
  Cc: ganesh.venkatesan, ganesh.venkatesan, hejianj, anton, rende,
	jesse.brandeburg, jgarzik, wangjs, john.ronciak, cdlwangl,
	linuxppc64-dev, netdev
In-Reply-To: <20050527012626.GA17294@gondor.apana.org.au>

Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
>  On Thu, May 26, 2005 at 05:28:55PM -0700, Venkatesan, Ganesh wrote:
>  > Would adding flush_sheduled_tasks() to e100_down, do it?
> 
>  Even though it might be OK it's probably not a good idea to have
>  the task flush itself while it's running.

flush_workqueue() handles that case.

^ permalink raw reply

* Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree
From: Jeff Garzik @ 2005-05-27  2:16 UTC (permalink / raw)
  To: Francois Romieu
  Cc: Grant Grundler, akpm, T-Bone, varenet, Linux Kernel, Netdev
In-Reply-To: <20050521223959.GA4337@electric-eye.fr.zoreil.com>

Francois Romieu wrote:
> Jeff Garzik <jgarzik@pobox.com> :
> [tulip_media_select]
> 
>>1) called from timer context, from the media poll timer
>>
>>2) called from spin_lock_irqsave() context, in the ->tx_timeout hook.
>>
>>The first case can be fixed by moved all the timer code to a workqueue. 
>> Then when the existing timer fires, kick the workqueue.
>>
>>The second case can be fixed by kicking the workqueue upon tx_timeout 
>>(which is the reason why I did not suggest queue_delayed_work() use).
> 
> 
> First try below. It only moves tulip_select_media() to process context.
> The original patch (with s/udelay/msleep/ or such) is not included.
> 
> Patch applies/compiles against 2.6.12-rc4.

Looks pretty good to me, at first look.

I'll give it some thought, and probably apply it, in a few days.

	Jeff

^ permalink raw reply

* [ANNOUNCE] Neterion(S2io) 10GbE Xframe Programming Manual posted
From: Leonid Grossman @ 2005-05-27  3:02 UTC (permalink / raw)
  To: netdev; +Cc: linux-net, linux-kernel
In-Reply-To: <20050316123828.0eb78fd3@dxpl.pdx.osdl.net>

For people interested in "s2io" 10GbE driver, the programming manual for
Xframe-I 10GbE Adapter 
is now available at ftp: ns1.s2io.com user: "linuxdocs" password: "HALdocs"

The relatively small delta between sw-compatible Xframe-II and Xframe-I is
not covered in the document,
but the current driver supports both adapters. Patches for the extra
Xframe-II features will be added over time; 
One of them (UDP Send Offload) was posted earlier today.


^ permalink raw reply

* Re: Re: [PATCH] (6/6) bridge: receive path optimization
From: Atul Sabharwal @ 2005-05-27  5:57 UTC (permalink / raw)
  To: shemminger, David S. Miller; +Cc: netdev, bridge
In-Reply-To: <20050526.155401.18310361.davem@davemloft.net>

I have a question about using the 802.1d driver with a switch.  I have a 
managed switch
which connects to the Xscale MAC using a Reverse MII interface.

It seems that the 802.1d bridge puts the interface into promiscuous mode and 
needs multiple
ethernet devices to work with.  Can it work with a single ethernet device 
which is connected
to a BCM5338 ( broadcomm 8 port switch chip ).

I understand that I would have to change the STP configuration component to 
write to the
broadcomm chip.

The chip supports direct memory mapped I/O of BPDU's using polled 
xmite/recieve using
a SPI interface.  Since I use a soft SPI stack, I cannot go faster than 
2MHz. Besides this
is a serial interface.

Suggestion, comments on both choices are highly appreciated.  I am working 
in a custom
enviornment with main objective of detecting loops in a cascade of switches. 
The physical
interconnect of the switches could be linear, tree, star or graph topology.

Also, the spanning tree needs to reconverge when switches are 
connected/disconnected.
Since there are no interrupts from the BCM5338, most of the implementation 
would be
based of polling.  Maybe, a forwarding delay of 5s should work as this is a 
LAN environment.

--
Atul
Linux Engineer 

^ permalink raw reply

* Network driver test suite (part 2)
From: Michael Renzmann @ 2005-05-27  6:14 UTC (permalink / raw)
  To: netdev

Hi all.

I vaguely remembered there was a discussion about a test suite which 
allows to check whether a network driver works as intended. After 
digging my local message archives I found the thread with the above 
title, but it seems the thread ceased without any result (apart from a 
wishlist for such a test suite).

Hence my question: is there such a test suite available now? If not, did 
anyone at least start working on such a project? What do you others 
usually use to test-drive a network driver?

Bye, Mike

^ permalink raw reply

* Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4
From: Jian Jun He @ 2005-05-27  6:18 UTC (permalink / raw)
  To: Andrew Morton
  Cc: anton, Dang En Ren, ganesh.venkatesan, ganesh.venkatesan, herbert,
	jesse.brandeburg, jgarzik, Jia Sen Wang, john.ronciak,
	Lei CDL Wang, linuxppc64-dev, netdev
In-Reply-To: <20050526133123.47824405.akpm@osdl.org>


[-- Attachment #1.1.1: Type: text/plain, Size: 4505 bytes --]



hello,

I verified the problem on 2.6.12-rc5 with mm1 patch. The test server works
find during the test procedure.
So I will close this defect in bugme.

Thanks all of your attention on this defect.


to Andrew Morton:

1)If you are a register in rhn.redhat.com, you can search the package
"rhr2", then you can download rhr2.
Also you could download rhr2 from the following links
http://people.redhat.com/rlandry/rhr2/test/1.0-17beta/rhr2-1.0-17beta.noarch.rpm

2)The attachments are the conf files that I used for rhr2 test.


(See attached file: hardware.conf)(See attached file: rhr.conf)(See
attached file: system.conf)(See attached file: tests.conf)
3) invoke redhat-ready is ok, no arguments.

Best Regards!

Jian Jun He

CSDL, Beijing
Email: hejianj@cn.ibm.com



                                                                       
             Andrew Morton                                             
             <akpm@osdl.org>                                           
                                                                        To
             2005-05-27 04:31          Jian Jun He/China/Contr/IBM@IBMCN
                                                                        cc
                                       ganesh.venkatesan@intel.com,    
                                       anton@samba.org, Dang En        
                                       Ren/China/IBM@IBMCN,            
                                       ganesh.venkatesan@gmail.com,    
                                       herbert@gondor.apana.org.au,    
                                       jesse.brandeburg@intel.com,     
                                       jgarzik@pobox.com, Jia Sen      
                                       Wang/China/IBM@IBMCN,           
                                       john.ronciak@intel.com, Lei CDL 
                                       Wang/China/Contr/IBM@IBMCN,     
                                       linuxppc64-dev@lists.linuxppc.org.s
                                       gi.com, netdev@oss.sgi.com      
                                                                   Subject
                                       Re: Fw: [Bugme-new] [Bug 4628] New:
                                       Test server hang while running rhr
                                       (network) test on RHEL4 with kernel
                                       2.6.12-rc1-mm4                  
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       




Jian Jun He <hejianj@cn.ibm.com> wrote:
>
>  2. Download rhr2-rhel4-1.0-14a.noarch.rpm from rhn.redhat.com and
install
>  it on
>  the test machine.
>  3. Configure and run the rhr test via invoking redhat-ready.

This is the problematic bit.

- Please provide a full URL which can be used to obtain rhr.
  rhn.redhat.com is subscription-based.

- Please describe the hardware setup - surely the test requires at least
  two machines.  How are they configured?

- Provide an exact transcript of the commands which are to be used.  Is
  it just

             redhat-ready

  with no arguments?



All that begin said, we already have a quite specific diagnosis via code
inspection, from Herbert:


Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > Might be a bug in the e100 driver, might not be.
> >
> > I assume this is the
> >
> >        BUG_ON(skb->list != NULL);
>
> It certainly is a bug in e100.
>
> e100_tx_timeout -> e100_down -> e100_rx_clean_list
>
> is racing against
>
> e100_poll -> e100_rx_clean -> e100_rx_indicate
>
> e100_rx_clean/e100_rx_indicate takes an skb off the RX ring and
> while it's being processed e100_rx_clean_list comes along and
> frees it.
>
> From a quick check similar problems may exist in other drivers that
> have lockless ->poll() functions with RX rings.

Do the e100 maintainers agree with this diagnosis?  If so then more testing
isn't required at this stage - the next step is to fix the above bug, no?


[-- Attachment #1.1.2: Type: text/html, Size: 5738 bytes --]

[-- Attachment #1.2: graycol.gif --]
[-- Type: image/gif, Size: 105 bytes --]

[-- Attachment #1.3: pic09902.gif --]
[-- Type: image/gif, Size: 1255 bytes --]

[-- Attachment #1.4: ecblank.gif --]
[-- Type: image/gif, Size: 45 bytes --]

[-- Attachment #2: hardware.conf --]
[-- Type: application/octet-stream, Size: 1672 bytes --]

#
# hardware.conf - generated on Fri May 27 00:41:46 EDT 2005
#

# DESCRIPTION:  This file contains the hardware class followed by any options
# required by that class tests; usually to include the device or number of
# devices to tests.
#
# CHANGES:  The largest change is that this file is now generated instead of
# manually populated.  With any luck this should avoid the need for a person
# to figure it out.  The format is largely in tact (compared with rhr.conf) 
# with two exceptions; the requirement to list the same device multiple times
# has been lifted (you may now assume the tests will do the right thing) and
# the test specific configuration data is now in /etc/rhr/tests.conf; more akin
# to rhr-crush and its /etc/rhr/kernel.

# NETWORK if1 [...ifN]
#   Requires a server and remote user as configured in /etc/rhr/tests.conf.
#   The remote user will need ab and mount privileges; the server is expected
#   to NOT be in a production environment as no password logins are enabled
#   during testing.
#
# *NOTE: On s390/s390x you may need to manually create the network scripts.
#        See the RELEASE-NOTES for details.
NETWORK eth0(100)

# STORAGE - list devices; includes both fixed disks, removable, and MTD's.
STORAGE sdc

# CORE (no parameters)
#   While there no parameters here; a kernel source RPM package is required for #   testing.  The package location is configured in /etc/rhr/tests.conf and is
#   shared by MEMORY
CORE 

# MEMORY (no parameters)
#   While there no parameters here; a kernel source RPM package is required for #   testing.  The package location is configured in /etc/rhr/tests.conf and is
#   shared by CORE.
MEMORY 


[-- Attachment #3: rhr.conf --]
[-- Type: application/octet-stream, Size: 509 bytes --]

#
# rhr.conf - generated Sun Aug 10 23:04:45 EDT 2003
#

# Description:  Allows for the use of alternate locations for the scratch and
# result files.  This prevents the need for bind-mounts and any other voodoo
# that could adversely effect the tests.  Defaults have been coded into the
# application so configuration is not required.  To override these values,
# uncomment the setting line and modify as needed.

# runtime temporary files.
SCRATCH=/tmp/rhr

# results package location.
RESULTS=/redhatready

[-- Attachment #4: system.conf --]
[-- Type: application/octet-stream, Size: 226 bytes --]

#
# system.conf - generated on Fri May 27 00:41:35 EDT 2005
# 

# DESCRIPTION:  Contains the make/model/release combination for HCL listing
# and results package creation. 

MAKE="make"
MODEL="IBM,9124-720"
RHRELEASE="Nahant"

[-- Attachment #5: tests.conf --]
[-- Type: application/octet-stream, Size: 1253 bytes --]

#
# tests.conf - test specific configuration file
#


#
# CORE
#
#  SRPM - Required kernel source rpm package; if not set, CORE will attempt
#         to locate and use the first kernel-*.src.rpm file it find in /tmp.
#
SRPM="/tmp/kernel-2.6.9-1.906.2.1_EL.patchtest.15.src.rpm"

#
# CDROM
#
#  ISO - Used for cd-r and cd-rw testing; cdrom testing requires a physical CD.
#        We're not specific on what has to be on the iso; however it should be
#        of a reasonable size.  Generally we recomend disc 1 of the install set.
#        Like SRPM above; if not set we'll settle for what we can find in /tmp.
#
#  NOTE: IF cd-r(w) and dvd-r(w) are to be run in the same pass, each iso
#        must be specified below.
#
#CDISO="/tmp/taroon-i386-as-disc1.iso"
#DVDISO="/tmp/taroon-i386-as-disc1.iso"


#
# NETWORK:
#
#  RHRUSER - The user used to log into the remote machine; should have
#            an ssh shell account and permissions to execute ab (apache bench),
#            and mount file systems.  The default user is root.
#
RHRUSER="root"
#
#  SERVER - The remote machine to be contacted; should contain the RHRUSER and
#           have apache bench (ab) and be able to mount NFS; defaults to
#           192.168.0.1.
#
SERVER="9.3.189.61"

^ permalink raw reply

* Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree
From: Francois Romieu @ 2005-05-27  7:17 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: Francois Romieu, Grant Grundler, akpm, T-Bone, varenet,
	Linux Kernel, Netdev
In-Reply-To: <42968312.90901@pobox.com>

Jeff Garzik <jgarzik@pobox.com> :
[...]
> Looks pretty good to me, at first look.
> 
> I'll give it some thought, and probably apply it, in a few days.

An updated version is cooking.

--
Ueimor

^ permalink raw reply

* Re: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path
From: Harald Welte @ 2005-05-27  7:37 UTC (permalink / raw)
  To: Herbert Xu; +Cc: netdev, netfilter-devel
In-Reply-To: <E1DbQ49-00027X-00@gondolin.me.apana.org.au>

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

On Fri, May 27, 2005 at 07:38:57AM +1000, Herbert Xu wrote:
> Harald Welte <laforge@netfilter.org> wrote:
> > 
> > The patch below adds an additional queue for ip_queue verdicts.  They
> > come up from userspace, are appended to a queue which is then processed
> > by a tasklet.  The tasklet itself runs in softirq context, so when timer
> > hardirq leaves, no tcp_delack_timer() will be executed until
> > nf_reinject() has finished.
> 
> This seems to be overly complicated if all you want is to do this in
> softirq context.  What's wrong with simply alling local_bh_disable?

Patrick just pointed this out, too.  I wasn't sure whether
local_bh_disable() would make the context really look like softirq in
every way.  If yes, it would certainly solve the problem, because
in_interrupt() at hardirq-exit would be true and therefore the timer
softirq not scheduled immediately.

I'll have Astaro test this variant.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: A new driver for Broadcom bcm5706
From: Christoph Hellwig @ 2005-05-27  7:41 UTC (permalink / raw)
  To: Michael Chan; +Cc: davem, jgarzik, netdev, ffan, lusinsky
In-Reply-To: <1116609329.31523.16.camel@rh4>

On Fri, May 20, 2005 at 10:15:29AM -0700, Michael Chan wrote:
> A new driver bnx2 for Broadcom bcm5706 is available. Since the patch is
> over 500K, I've put it on the ftp server:
> 
> ftp://Net_sys_anon@ftp1.broadcom.com/bnx2-2.patch
> 
> The patch also includes new 1000BASE-X advertisement bit definitions in
> mii.h

These defintions overlap older 10MB/s defintions.  I don't think the number
space is scare enough to need this hack.  If we absolutely want to keep it
you should at least add some big comments explaining it.

^ permalink raw reply

* Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4
From: Andrew Morton @ 2005-05-27  8:21 UTC (permalink / raw)
  To: Jian Jun He
  Cc: anton, rende, ganesh.venkatesan, ganesh.venkatesan, herbert,
	jesse.brandeburg, jgarzik, wangjs, john.ronciak, cdlwangl,
	linuxppc64-dev, netdev
In-Reply-To: <OF8C2BEBF0.DC03FA25-ON4825700E.001E3C15-4825700E.0022793E@cn.ibm.com>

Jian Jun He <hejianj@cn.ibm.com> wrote:
>
> I verified the problem on 2.6.12-rc5 with mm1 patch. The test server works
>  find during the test procedure.

Great, thanks.

>  So I will close this defect in bugme.

Well we should verify that the e100 patches which Linus merged a few hours
ago did contain the fix.  So please test 2.6.12-rc5-git2, which should be
at ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots in ~8 hours.

^ permalink raw reply

* RFC: NAPI packet weighting patch
From: Robert Olsson @ 2005-05-27  8:21 UTC (permalink / raw)
  To: Mitch Williams; +Cc: netdev, john.ronciak, ganesh.venkatesan, jesse.brandeburg
In-Reply-To: <Pine.CYG.4.58.0505261406210.2364@mawilli1-desk2.amr.corp.intel.com>


 Hello!
 Some comments below.

Mitch Williams writes:

 > With the parameter set to 0 (the default), NAPI polling works exactly as
 > it does today:  each packet is worth one backlog work unit, and the
 > maximum number of received packets that will be processed in any given
 > softirq is controlled by the 'netdev_max_backlog' parameter.

 You should be able to accomplish on per-device basis with dev->weight 

 > By increasing the packet weight, we accomplish two things:  first, we
 > cause the individual NAPI RX loops in each driver to process fewer
 > packets.  This means that they will free up RX resources to the hardware
 > more often, which reduces the possibility of dropped packets.  

 I kind of interesting area and complex as weight setting should consider
 coalicing etc.as we try find an acceptable balance of interrupts, polls.
 and packtets per poll. Again to me this indicates that this should be done 
 on driver level.

 Do you have more details about the cases your were able to improve and how 
 your thingking was here. It's kind of unresearched area.

 > Second, it shortens the total time spent in the NAPI softirq, which can 
 > free the CPU to handle other tasks more often, thus reducing overall latency.

 At high packet load from several dev's we still only break the RX softirq 
 when exhausting the total budget or a jiffie. Generally the RX softirq is very 
 well-behaved due to this.

 Cheers.
					--ro

^ permalink raw reply

* Re: LC-trie FIB major rework
From: Robert Olsson @ 2005-05-27  9:04 UTC (permalink / raw)
  To: David S. Miller; +Cc: Robert.Olsson, netdev
In-Reply-To: <20050526.133815.62342715.davem@davemloft.net>

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1031 bytes --]


David S. Miller writes:

 > > Below much reworked version of the LC-trie for FIB lookup's. Much closer
 > > to current FIB anatomy and locking. Parent pointers in the trie to avoid 
 > > own stacks etc. The option to merge tables has been removed and much things 
 > > to keep things as simple and clean as possible. Although it's somewhat 
 > > complex. 
 > >  
 > > Performance. We now perform about 25-30% better than current FIB in 
 > > heavy lookup situations (we test with full rDoS) The test below illustrates
 > > this 123 kroutes in the routing table and rDoS is injected into eth0 at 
 > > 720 kpps routed traffic on eth1/eth3. route hash is not used and both 
 > > dst and src are looked up. LC-trie should work fine any size of routing table..
 > 
 > Very nice work Robert.  Once TSO becomes less of a time sink I
 > intend to help you out a bit.

 Thanks!
 Appreciate that.. take your time.

 Seems the patch wasn't distributed on the list probably due to size. 
 So below is a gzipped version.

 Cheers.
					--ro


[-- Attachment #2: trie.pat.gz --]
[-- Type: application/octet-stream, Size: 17082 bytes --]

^ permalink raw reply

* Re: Fw: [Bugme-new] [Bug 4628] New: Test server hang while running rhr (network) test on RHEL4 with kernel 2.6.12-rc1-mm4
From: Jian Jun He @ 2005-05-27 10:12 UTC (permalink / raw)
  To: Andrew Morton
  Cc: anton, Dang En Ren, ganesh.venkatesan, ganesh.venkatesan, herbert,
	jesse.brandeburg, jgarzik, Jia Sen Wang, john.ronciak,
	Lei CDL Wang, linuxppc64-dev, netdev
In-Reply-To: <20050527012101.4b80c005.akpm@osdl.org>


[-- Attachment #1.1: Type: text/plain, Size: 2735 bytes --]


I will verify it on 2.6.12-rc5-git2 when it is ready.


Best Regards!

Jian Jun He

CSDL, Beijing
Email: hejianj@cn.ibm.com



                                                                       
             Andrew Morton                                             
             <akpm@osdl.org>                                           
                                                                        To
             2005-05-27 16:21          Jian Jun He/China/Contr/IBM@IBMCN
                                                                        cc
                                       anton@samba.org, Dang En        
                                       Ren/China/IBM@IBMCN,            
                                       ganesh.venkatesan@gmail.com,    
                                       ganesh.venkatesan@intel.com,    
                                       herbert@gondor.apana.org.au,    
                                       jesse.brandeburg@intel.com,     
                                       jgarzik@pobox.com, Jia Sen      
                                       Wang/China/IBM@IBMCN,           
                                       john.ronciak@intel.com, Lei CDL 
                                       Wang/China/Contr/IBM@IBMCN,     
                                       linuxppc64-dev@lists.linuxppc.org.s
                                       gi.com, netdev@oss.sgi.com      
                                                                   Subject
                                       Re: Fw: [Bugme-new] [Bug 4628] New:
                                       Test server hang while running rhr
                                       (network) test on RHEL4 with kernel
                                       2.6.12-rc1-mm4                  
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       




Jian Jun He <hejianj@cn.ibm.com> wrote:
>
> I verified the problem on 2.6.12-rc5 with mm1 patch. The test server
works
>  find during the test procedure.

Great, thanks.

>  So I will close this defect in bugme.

Well we should verify that the e100 patches which Linus merged a few hours
ago did contain the fix.  So please test 2.6.12-rc5-git2, which should be
at ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots in ~8 hours.



[-- Attachment #1.2: Type: text/html, Size: 3505 bytes --]

[-- Attachment #2: graycol.gif --]
[-- Type: image/gif, Size: 105 bytes --]

[-- Attachment #3: pic10544.gif --]
[-- Type: image/gif, Size: 1255 bytes --]

[-- Attachment #4: ecblank.gif --]
[-- Type: image/gif, Size: 45 bytes --]

^ permalink raw reply

* [6/10] [IPSEC] Use XFRM_MSG_* instead of XFRM_SAP_*
From: Herbert Xu @ 2005-05-27 11:11 UTC (permalink / raw)
  To: David S. Miller, jamal, Patrick McHardy, netdev
In-Reply-To: <20050527111037.GE4545@gondor.apana.org.au>

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

This patch removes XFRM_SAP_* and converts them over to XFRM_MSG_*.
The netlink interface is meant to map directly onto the underlying
xfrm subsystem.  Therefore rather than using a new independent
representation for the events we can simply use the existing ones
from xfrm_user.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[-- Attachment #2: p6.patch --]
[-- Type: text/plain, Size: 10103 bytes --]

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -158,18 +158,6 @@ enum {
 	XFRM_STATE_DEAD
 };
 
-/* events that could be sent by kernel */
-enum {
-	XFRM_SAP_INVALID,
-	XFRM_SAP_EXPIRED,
-	XFRM_SAP_ADDED,
-	XFRM_SAP_UPDATED,
-	XFRM_SAP_DELETED,
-	XFRM_SAP_FLUSHED,
-	__XFRM_SAP_MAX
-};
-#define XFRM_SAP_MAX (__XFRM_SAP_MAX - 1)
-
 /* callback structure passed from either netlink or pfkey */
 struct km_event
 {
diff --git a/net/key/af_key.c b/net/key/af_key.c
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -1248,13 +1248,13 @@ static int pfkey_acquire(struct sock *sk
 static inline int event2poltype(int event)
 {
 	switch (event) {
-	case XFRM_SAP_DELETED:
+	case XFRM_MSG_DELPOLICY:
 		return SADB_X_SPDDELETE;
-	case XFRM_SAP_ADDED:
+	case XFRM_MSG_NEWPOLICY:
 		return SADB_X_SPDADD;
-	case XFRM_SAP_UPDATED:
+	case XFRM_MSG_UPDPOLICY:
 		return SADB_X_SPDUPDATE;
-	case XFRM_SAP_EXPIRED:
+	case XFRM_MSG_POLEXPIRE:
 	//	return SADB_X_SPDEXPIRE;
 	default:
 		printk("pfkey: Unknown policy event %d\n", event);
@@ -1267,13 +1267,13 @@ static inline int event2poltype(int even
 static inline int event2keytype(int event)
 {
 	switch (event) {
-	case XFRM_SAP_DELETED:
+	case XFRM_MSG_DELSA:
 		return SADB_DELETE;
-	case XFRM_SAP_ADDED:
+	case XFRM_MSG_NEWSA:
 		return SADB_ADD;
-	case XFRM_SAP_UPDATED:
+	case XFRM_MSG_UPDSA:
 		return SADB_UPDATE;
-	case XFRM_SAP_EXPIRED:
+	case XFRM_MSG_EXPIRE:
 		return SADB_EXPIRE;
 	default:
 		printk("pfkey: Unknown SA event %d\n", event);
@@ -1290,7 +1290,7 @@ static int key_notify_sa(struct xfrm_sta
 	struct sadb_msg *hdr;
 	int hsc = 3;
 
-	if (c->event == XFRM_SAP_DELETED)
+	if (c->event == XFRM_MSG_DELSA)
 		hsc = 0;
 
 	skb = pfkey_xfrm_state2msg(x, 0, hsc);
@@ -1337,9 +1337,9 @@ static int pfkey_add(struct sock *sk, st
 	}
 
 	if (hdr->sadb_msg_type == SADB_ADD)
-		c.event = XFRM_SAP_ADDED;
+		c.event = XFRM_MSG_NEWSA;
 	else
-		c.event = XFRM_SAP_UPDATED;
+		c.event = XFRM_MSG_UPDSA;
 	c.seq = hdr->sadb_msg_seq;
 	c.pid = hdr->sadb_msg_pid;
 	km_state_notify(x, &c);
@@ -1376,7 +1376,7 @@ static int pfkey_delete(struct sock *sk,
 
 	c.seq = hdr->sadb_msg_seq;
 	c.pid = hdr->sadb_msg_pid;
-	c.event = XFRM_SAP_DELETED;
+	c.event = XFRM_MSG_DELSA;
 	km_state_notify(x, &c);
 	xfrm_state_put(x);
 
@@ -1552,7 +1552,7 @@ static int pfkey_flush(struct sock *sk, 
 	c.data.proto = proto;
 	c.seq = hdr->sadb_msg_seq;
 	c.pid = hdr->sadb_msg_pid;
-	c.event = XFRM_SAP_FLUSHED;
+	c.event = XFRM_MSG_FLUSHSA;
 	km_state_notify(NULL, &c);
 
 	return 0;
@@ -1962,7 +1962,7 @@ static int key_notify_policy(struct xfrm
 	out_hdr = (struct sadb_msg *) out_skb->data;
 	out_hdr->sadb_msg_version = PF_KEY_V2;
 
-	if (c->data.byid && c->event == XFRM_SAP_DELETED)
+	if (c->data.byid && c->event == XFRM_MSG_DELPOLICY)
 		out_hdr->sadb_msg_type = SADB_X_SPDDELETE2;
 	else
 		out_hdr->sadb_msg_type = event2poltype(c->event);
@@ -2058,9 +2058,9 @@ static int pfkey_spdadd(struct sock *sk,
 	}
 
 	if (hdr->sadb_msg_type == SADB_X_SPDUPDATE)
-		c.event = XFRM_SAP_UPDATED;
-	else
-		c.event = XFRM_SAP_ADDED;
+		c.event = XFRM_MSG_UPDPOLICY;
+	else 
+		c.event = XFRM_MSG_NEWPOLICY;
 
 	c.seq = hdr->sadb_msg_seq;
 	c.pid = hdr->sadb_msg_pid;
@@ -2118,7 +2118,7 @@ static int pfkey_spddelete(struct sock *
 
 	c.seq = hdr->sadb_msg_seq;
 	c.pid = hdr->sadb_msg_pid;
-	c.event = XFRM_SAP_DELETED;
+	c.event = XFRM_MSG_DELPOLICY;
 	km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c);
 
 	xfrm_pol_put(xp);
@@ -2174,7 +2174,7 @@ static int pfkey_spdget(struct sock *sk,
 	c.pid = hdr->sadb_msg_pid;
 	if (hdr->sadb_msg_type == SADB_X_SPDDELETE2) {
 		c.data.byid = 1;
-		c.event = XFRM_SAP_DELETED;
+		c.event = XFRM_MSG_DELPOLICY;
 		km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c);
 	} else {
 		err = key_pol_get_resp(sk, xp, hdr, pol->sadb_x_policy_dir-1);
@@ -2238,7 +2238,7 @@ static int pfkey_spdflush(struct sock *s
 	struct km_event c;
 
 	xfrm_policy_flush();
-	c.event = XFRM_SAP_FLUSHED;
+	c.event = XFRM_MSG_FLUSHPOLICY;
 	c.pid = hdr->sadb_msg_pid;
 	c.seq = hdr->sadb_msg_seq;
 	km_policy_notify(NULL, 0, &c);
@@ -2479,13 +2479,13 @@ static int key_notify_sa_expire(struct x
 static int pfkey_send_notify(struct xfrm_state *x, struct km_event *c)
 {
 	switch (c->event) {
-	case XFRM_SAP_EXPIRED:
+	case XFRM_MSG_EXPIRE:
 		return key_notify_sa_expire(x, c);
-	case XFRM_SAP_DELETED:
-	case XFRM_SAP_ADDED:
-	case XFRM_SAP_UPDATED:
+	case XFRM_MSG_DELSA:
+	case XFRM_MSG_NEWSA:
+	case XFRM_MSG_UPDSA:
 		return key_notify_sa(x, c);
-	case XFRM_SAP_FLUSHED:
+	case XFRM_MSG_FLUSHSA:
 		return key_notify_sa_flush(c);
 	default:
 		printk("pfkey: Unknown SA event %d\n", c->event);
@@ -2498,13 +2498,13 @@ static int pfkey_send_notify(struct xfrm
 static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, struct km_event *c)
 {
 	switch (c->event) {
-	case XFRM_SAP_EXPIRED:
+	case XFRM_MSG_POLEXPIRE:
 		return key_notify_policy_expire(xp, c);
-	case XFRM_SAP_DELETED:
-	case XFRM_SAP_ADDED:
-	case XFRM_SAP_UPDATED:
+	case XFRM_MSG_DELPOLICY:
+	case XFRM_MSG_NEWPOLICY:
+	case XFRM_MSG_UPDPOLICY:
 		return key_notify_policy(xp, dir, c);
-	case XFRM_SAP_FLUSHED:
+	case XFRM_MSG_FLUSHPOLICY:
 		return key_notify_policy_flush(c);
 	default:
 		printk("pfkey: Unknown policy event %d\n", c->event);
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -836,7 +836,7 @@ static void km_state_expired(struct xfrm
 	struct km_event c;
 
 	c.data.hard = hard;
-	c.event = XFRM_SAP_EXPIRED;
+	c.event = XFRM_MSG_EXPIRE;
 	km_state_notify(x, &c);
 
 	if (hard)
@@ -884,7 +884,7 @@ void km_policy_expired(struct xfrm_polic
 	struct km_event c;
 
 	c.data.hard = hard;
-	c.event = XFRM_SAP_EXPIRED;
+	c.event = XFRM_MSG_POLEXPIRE;
 	km_policy_notify(pol, dir, &c);
 
 	if (hard)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -292,10 +292,7 @@ static int xfrm_add_sa(struct sk_buff *s
 
 	c.seq = nlh->nlmsg_seq;
 	c.pid = nlh->nlmsg_pid;
-	if (nlh->nlmsg_type == XFRM_MSG_NEWSA)
-		c.event = XFRM_SAP_ADDED;
-	else
-		c.event = XFRM_SAP_UPDATED;
+	c.event = nlh->nlmsg_type;
 
 	km_state_notify(x, &c);
 	xfrm_state_put(x);
@@ -327,7 +324,7 @@ static int xfrm_del_sa(struct sk_buff *s
 
 	c.seq = nlh->nlmsg_seq;
 	c.pid = nlh->nlmsg_pid;
-	c.event = XFRM_SAP_DELETED;
+	c.event = nlh->nlmsg_type;
 	km_state_notify(x, &c);
 	xfrm_state_put(x);
 
@@ -719,11 +716,7 @@ static int xfrm_add_policy(struct sk_buf
 		return err;
 	}
 
-	if (!excl)
-		c.event = XFRM_SAP_UPDATED;
-	else
-		c.event = XFRM_SAP_ADDED;
-
+	c.event = nlh->nlmsg_type;
 	c.seq = nlh->nlmsg_seq;
 	c.pid = nlh->nlmsg_pid;
 	km_policy_notify(xp, p->dir, &c);
@@ -875,7 +868,7 @@ static int xfrm_get_policy(struct sk_buf
 		}
 	} else {
 		c.data.byid = p->index;
-		c.event = XFRM_SAP_DELETED;
+		c.event = nlh->nlmsg_type;
 		c.seq = nlh->nlmsg_seq;
 		c.pid = nlh->nlmsg_pid;
 		km_policy_notify(xp, p->dir, &c);
@@ -893,7 +886,7 @@ static int xfrm_flush_sa(struct sk_buff 
 
 	xfrm_state_flush(p->proto);
 	c.data.proto = p->proto;
-	c.event = XFRM_SAP_FLUSHED;
+	c.event = nlh->nlmsg_type;
 	c.seq = nlh->nlmsg_seq;
 	c.pid = nlh->nlmsg_pid;
 	km_state_notify(NULL, &c);
@@ -906,7 +899,7 @@ static int xfrm_flush_policy(struct sk_b
 	struct km_event c;
 
 	xfrm_policy_flush();
-	c.event = XFRM_SAP_FLUSHED;
+	c.event = nlh->nlmsg_type;
 	c.seq = nlh->nlmsg_seq;
 	c.pid = nlh->nlmsg_pid;
 	km_policy_notify(NULL, 0, &c);
@@ -1184,7 +1177,6 @@ static int xfrm_notify_sa(struct xfrm_st
 	struct xfrm_usersa_info *p;
 	struct nlmsghdr *nlh;
 	struct sk_buff *skb;
-	u32 nlt;
 	unsigned char *b;
 	int len = xfrm_sa_len(x);
 
@@ -1193,16 +1185,7 @@ static int xfrm_notify_sa(struct xfrm_st
 		return -ENOMEM;
 	b = skb->tail;
 
-	if (c->event == XFRM_SAP_ADDED)
-		nlt = XFRM_MSG_NEWSA;
-	else if (c->event == XFRM_SAP_UPDATED)
-		nlt = XFRM_MSG_UPDSA;
-	else if (c->event == XFRM_SAP_DELETED)
-		nlt = XFRM_MSG_DELSA;
-	else
-		goto nlmsg_failure;
-
-	nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p));
+	nlh = NLMSG_PUT(skb, c->pid, c->seq, c->event, sizeof(*p));
 	nlh->nlmsg_flags = 0;
 
 	p = NLMSG_DATA(nlh);
@@ -1234,13 +1217,13 @@ static int xfrm_send_state_notify(struct
 {
 
 	switch (c->event) {
-	case XFRM_SAP_EXPIRED:
+	case XFRM_MSG_EXPIRE:
 		return xfrm_exp_state_notify(x, c);
-	case XFRM_SAP_DELETED:
-	case XFRM_SAP_UPDATED:
-	case XFRM_SAP_ADDED:
+	case XFRM_MSG_DELSA:
+	case XFRM_MSG_UPDSA:
+	case XFRM_MSG_NEWSA:
 		return xfrm_notify_sa(x, c);
-	case XFRM_SAP_FLUSHED:
+	case XFRM_MSG_FLUSHSA:
 		return xfrm_notify_sa_flush(c);
 	default:
 		 printk("xfrm_user: Unknown SA event %d\n", c->event);
@@ -1408,7 +1391,6 @@ static int xfrm_notify_policy(struct xfr
 	struct xfrm_userpolicy_info *p;
 	struct nlmsghdr *nlh;
 	struct sk_buff *skb;
-	u32 nlt = 0 ;
 	unsigned char *b;
 	int len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp->xfrm_nr);
 	len += NLMSG_SPACE(sizeof(struct xfrm_userpolicy_info));
@@ -1418,16 +1400,7 @@ static int xfrm_notify_policy(struct xfr
 		return -ENOMEM;
 	b = skb->tail;
 
-	if (c->event == XFRM_SAP_ADDED)
-		nlt = XFRM_MSG_NEWPOLICY;
-	else if (c->event == XFRM_SAP_UPDATED)
-		nlt = XFRM_MSG_UPDPOLICY;
-	else if (c->event == XFRM_SAP_DELETED)
-		nlt = XFRM_MSG_DELPOLICY;
-	else
-		goto nlmsg_failure;
-
-	nlh = NLMSG_PUT(skb, c->pid, c->seq, nlt, sizeof(*p));
+	nlh = NLMSG_PUT(skb, c->pid, c->seq, c->event, sizeof(*p));
 
 	p = NLMSG_DATA(nlh);
 
@@ -1474,13 +1447,13 @@ static int xfrm_send_policy_notify(struc
 {
 
 	switch (c->event) {
-	case XFRM_SAP_ADDED:
-	case XFRM_SAP_UPDATED:
-	case XFRM_SAP_DELETED:
+	case XFRM_MSG_NEWPOLICY:
+	case XFRM_MSG_UPDPOLICY:
+	case XFRM_MSG_DELPOLICY:
 		return xfrm_notify_policy(xp, dir, c);
-	case XFRM_SAP_FLUSHED:
+	case XFRM_MSG_FLUSHPOLICY:
 		return xfrm_notify_policy_flush(c);
-	case XFRM_SAP_EXPIRED:
+	case XFRM_MSG_POLEXPIRE:
 		return xfrm_exp_policy_notify(xp, dir, c);
 	default:
 		printk("xfrm_user: Unknown Policy event %d\n", c->event);

^ permalink raw reply

* Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink
From: jamal @ 2005-05-27 11:14 UTC (permalink / raw)
  To: Thomas Graf; +Cc: David S. Miller, netdev
In-Reply-To: <20050526185526.GZ15391@postel.suug.ch>

On Thu, 2005-26-05 at 20:55 +0200, Thomas Graf wrote:
> To retrieve the neighbour tables send RTM_GETNEIGHTBL with the
> NLM_F_DUMP flag set. Every neighbour table configuration is
> spread over multiple messages to avoid running into message
> size limits on systems with many interfaces. The first message
> in the sequence transports all not device specific data such as
> statistics, configuration, and the default parameter set.
> This message is followed by 0..n messages carrying device
> specific parameter sets. They all share the same value for
> Although the ordering should be sufficient, NDTA_NAME can be
> used to identify sequences. The initial message can be identified
> by checking for NDTA_CONFIG. The device specific messages do
> no contain this TLV but have NDTPA_IFINDEX set to the
> corresponding interface index.
> 
> To change neighbour table attributes, send RTM_SETNEIGHTBL
> with NDTA_NAME set. Changeable attribute include NDTA_THRESH[1-3],
> NDTA_GC_INTERVAL, and all TLVs in NDTA_PARMS unless marked
> otherwise. Device specific parameter sets can be changed by
> setting NDTPA_IFINDEX to the interface index of the corresponding
> device.

It would have been better, IMO, to just work on a generic idev/devinet
retrieval and setting instead of one component (as in ARP in this
case). 

cheers,
jamal

^ permalink raw reply

* [7/10] [IPSEC] Fix xfrm_state leaks in error path
From: Herbert Xu @ 2005-05-27 11:14 UTC (permalink / raw)
  To: David S. Miller, jamal, Patrick McHardy, netdev
In-Reply-To: <20050527111140.GF4545@gondor.apana.org.au>

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

Herbert Xu wrote:
> @@ -1254,6 +1326,7 @@ static int pfkey_add(struct sock *sk, st
>       if (IS_ERR(x))
>               return PTR_ERR(x);
>
> +     xfrm_state_hold(x);

This introduces a leak when xfrm_state_add()/xfrm_state_update()
fail. We hold two references (one from xfrm_state_alloc(), one
from xfrm_state_hold()), but only drop one. We need to take the
reference because the reference from xfrm_state_alloc() can
be dropped by __xfrm_state_delete(), so the fix is to drop both
references on error. Same problem in xfrm_user.c.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[-- Attachment #2: p9.patch --]
[-- Type: text/plain, Size: 969 bytes --]

diff --git a/net/key/af_key.c b/net/key/af_key.c
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -1333,7 +1333,7 @@ static int pfkey_add(struct sock *sk, st
 	if (err < 0) {
 		x->km.state = XFRM_STATE_DEAD;
 		xfrm_state_put(x);
-		return err;
+		goto out;
 	}
 
 	if (hdr->sadb_msg_type == SADB_ADD)
@@ -1343,8 +1343,8 @@ static int pfkey_add(struct sock *sk, st
 	c.seq = hdr->sadb_msg_seq;
 	c.pid = hdr->sadb_msg_pid;
 	km_state_notify(x, &c);
+out:
 	xfrm_state_put(x);
-
 	return err;
 }
 
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -287,7 +287,7 @@ static int xfrm_add_sa(struct sk_buff *s
 	if (err < 0) {
 		x->km.state = XFRM_STATE_DEAD;
 		xfrm_state_put(x);
-		return err;
+		goto out;
 	}
 
 	c.seq = nlh->nlmsg_seq;
@@ -295,8 +295,8 @@ static int xfrm_add_sa(struct sk_buff *s
 	c.event = nlh->nlmsg_type;
 
 	km_state_notify(x, &c);
+out:
 	xfrm_state_put(x);
-
 	return err;
 }
 

^ permalink raw reply

* [8/10] [IPSEC] Use NLMSG_LENGTH in xfrm_exp_state_notify
From: Herbert Xu @ 2005-05-27 11:15 UTC (permalink / raw)
  To: David S. Miller, jamal, Patrick McHardy, netdev
In-Reply-To: <20050527111458.GG4545@gondor.apana.org.au>

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

Small fixup to use netlink macros instead of hardcoding.

Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[-- Attachment #2: p10.patch --]
[-- Type: text/plain, Size: 497 bytes --]

diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1114,9 +1114,9 @@ nlmsg_failure:
 static int xfrm_exp_state_notify(struct xfrm_state *x, struct km_event *c)
 {
 	struct sk_buff *skb;
+	int len = NLMSG_LENGTH(sizeof(struct xfrm_user_expire));
 
-	/* fix to do alloc using NLM macros */
-	skb = alloc_skb(sizeof(struct xfrm_user_expire) + 16, GFP_ATOMIC);
+	skb = alloc_skb(len, GFP_ATOMIC);
 	if (skb == NULL)
 		return -ENOMEM;
 

^ permalink raw reply

* Re: RFC: NAPI packet weighting patch
From: jamal @ 2005-05-27 11:18 UTC (permalink / raw)
  To: Mitch Williams; +Cc: netdev, john.ronciak, ganesh.venkatesan, jesse.brandeburg
In-Reply-To: <Pine.CYG.4.58.0505261406210.2364@mawilli1-desk2.amr.corp.intel.com>

On Thu, 2005-26-05 at 14:36 -0700, Mitch Williams wrote:
> The following patch (which applies to 2.6.12rc4) adds a new sysctl
> parameter called 'netdev_packet_weight'.  This parameter controls how many
> backlog work units each RX packet is worth.
> 
> With the parameter set to 0 (the default), NAPI polling works exactly as
> it does today:  each packet is worth one backlog work unit, and the
> maximum number of received packets that will be processed in any given
> softirq is controlled by the 'netdev_max_backlog' parameter.
> 

NAPI uses already using a Weighted Round robin scheduling scheme know as
DRR.
I am not sure providing a weight scale on the weight is enhancing
anything. 
Did you try to just reduce the weight instead to make it smaller
instead? i.e take the resultant weight of you using a shift and set that
as the weight.

cheers,
jamal

 

^ permalink raw reply

* [9/10] Not quite...
From: Herbert Xu @ 2005-05-27 11:28 UTC (permalink / raw)
  To: David S. Miller, jamal, Patrick McHardy, netdev
In-Reply-To: <20050527111534.GH4545@gondor.apana.org.au>

Sorry, I incorrectly counted a patch that had been reverted.  So that's it
for now :)
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox