David S. Miller | 1 Aug 08:40 2004
X-Face
Picon

Re: SPI generation by netlink_get_spi()


Looks good to me.  Patch applied, thanks Herbert.

David S. Miller | 1 Aug 08:41 2004
X-Face
Picon

Re: [IPSEC] Remove redundant check in xfrm_state_add()

On Fri, 30 Jul 2004 22:10:56 +1000
Herbert Xu <herbert <at> gondor.apana.org.au> wrote:

> This is the patch referred to in the netlink_get_spi thread.

Yep, looks good.  Applied.

David S. Miller | 1 Aug 08:45 2004
X-Face
Picon

Re: [IPSEC] xfrm_alloc_spi always succeeds on non-trivial range

On Sat, 31 Jul 2004 12:00:44 +1000
Herbert Xu <herbert <at> gondor.apana.org.au> wrote:

> xfrm_alloc_spi will always succeed if minspi < maxspi, even if
> minspi + 1 == maxspi.  If the range is already occupied this
> will obviously lead to breakage.
> 
> Of course this is very unlikely to occur in reality due to the
> size of the range.  Although with IPCOMP it might actually happen
> on a very large server.
> 
> The fix is obivous.

Indeed, applied.

You're certainly making the rounds auditing the SPI handling lately.
:-)  It is much appreciated.

David S. Miller | 1 Aug 08:51 2004
X-Face
Picon

Re: [PFKEY] spirange should be in host byte order

On Sat, 31 Jul 2004 20:04:44 +1000
Herbert Xu <herbert <at> gondor.apana.org.au> wrote:

> So the conclusion is that we can and should change our PFKEY
> implementation to use host order for these fields.

I agree with this conclusion and have applied your patch.
Good thing we caught this now.

Thanks Herbert.

David S. Miller | 1 Aug 08:53 2004
X-Face
Picon

Re: [IPSEC PATCH] missing break in UDP decap code Re: (udp-en/decap broken in 2.6.8-rc2?) Re: ipsec, nat-t, iproute2?

On Sun, 1 Aug 2004 05:32:04 +1000
Herbert Xu <herbert <at> gondor.apana.org.au> wrote:

> On Sat, Jul 31, 2004 at 03:08:53PM +0200, bert hubert wrote:
> > 
> > Against 2.6.8-rc2, neatly solves the problem. The missing break causes the
> > packet to be tested against both encapsulation types, one will always fail.
> 
> Sorry, that was my fault.
> 
> Dave, please apply his patch to fix NON_ESP reception.

Done, thanks guys.

Adrian Bunk | 1 Aug 16:27 2004
Picon
Picon

[2.4 patch] CONFIG_NET_SCH_NETEM Configure.help entry

On Sat, Jul 31, 2004 at 11:26:59AM -0300, Marcelo Tosatti wrote:
>...
> Summary of changes from v2.4.27-rc3 to v2.4.27-rc4
> ============================================
>...
> Stephen Hemminger:
>   o [PKT_SCHED]: Update to network emulation QOS scheduler
>   o [PKT_SCHED]: One small netem fixes
>   o [BRIDGE]: Fix assertion failure in 2.4.27-rc3
>   o [PKT_SCHED]: netem update for 2.4
>...

The Configure.help entry was forgotten:

Signed-off-by: Adrian Bunk <bunk <at> fs.tum.de>

--- linux-2.4.27-rc4-full/Documentation/Configure.help.old	2004-08-01 16:20:15.000000000 +0200
+++ linux-2.4.27-rc4-full/Documentation/Configure.help	2004-08-01 16:22:23.000000000 +0200
 <at>  <at>  -10949,13 +10949,15  <at>  <at> 
   whenever you want). If you want to compile it as a module, say M
   here and read <file:Documentation/modules.txt>.

-Network delay simualtor  
-CONFIG_NET_SCH_DELAY
-  Say Y if you want to delay packets by a fixed amount of
-  time. This is often useful to simulate network delay when
+CONFIG_NET_SCH_NETEM
+  Say Y if you want to emulate network delay, loss, and packet
+  re-ordering. This is often useful to simulate networks when
   testing applications or protocols.
(Continue reading)

Adrian Bunk | 1 Aug 16:33 2004
Picon
Picon

[2.6 patch] update NET_SCH_NETEM help text

The patch below contains the following changes for the NET_SCH_NETEM 
help text:
- correct the module name
- "If unsure, say N."

Signed-off-by: Adrian Bunk <bunk <at> fs.tum.de>

--- linux-2.6.8-rc2-mm1-full/net/sched/Kconfig.old	2004-08-01 16:28:22.000000000 +0200
+++ linux-2.6.8-rc2-mm1-full/net/sched/Kconfig	2004-08-01 16:29:12.000000000 +0200
 <at>  <at>  -207,19 +207,21  <at>  <at> 
 config NET_SCH_NETEM
 	tristate "Network emulator"
 	depends on NET_SCHED
 	help
 	  Say Y if you want to emulate network delay, loss, and packet
 	  re-ordering. This is often useful to simulate networks when
 	  testing applications or protocols.

 	  To compile this driver as a module, choose M here: the module
-	  will be called sch_delay.
+	  will be called sch_netem.
+
+	  If unsure, say N.

 config NET_SCH_INGRESS
 	tristate "Ingress Qdisc"
 	depends on NET_SCHED 
 	help
 	  If you say Y here, you will be able to police incoming bandwidth
 	  and drop packets when this bandwidth exceeds your desired rate.
(Continue reading)

Randy.Dunlap | 1 Aug 19:22 2004
X-Face

Re: 2.6.7 kernel boot-time configuration of a non-modular tulip driver


(moving this to netdev mailing list)

On Sun, 01 Aug 2004 00:48:22 +1000 Bruce Janson wrote:

| I have a linux 2.6.7 kernel which contains a compiled-in tulip driver.
| I would like to be able to boot the kernel with parameters that
| will allow control of the tulip device.  On some ethernet devices
| this used to be possible via (something like):
| 
|   ether=0,0,1,0,eth0
| 
| which would pass the four numeric parameters (as, I think, dev->irq,
| dev->ioaddr, dev->mem_start and dev->mem_end) to the net driver that
| controlled eth0.  A convention adopted by some net drivers then allowed
| dev->mem_start to be interpretted as a set of flags that would control
| device characteristics (e.g. full-duplex vs half-duplex mode).
| In .../linux-2.6.7/drivers/net/tulip/tulip_core.c:1587:
| 
|   if (dev->mem_start & MEDIA_MASK)
|     tp->default_port = dev->mem_start & MEDIA_MASK;
| 
| suggests that this might still work.  However, I have been unable
| to force dev->mem_start in that driver to become non-zero via any
| kernel boot-time parameters.  My limited understanding of the code
| that precedes the above lines in that file suggests that the "dev"
| structure is not what it used to be...

The driver never calls netdev_boot_setup_check(), which is
what would give the driver its command line parameters.
(Continue reading)

Patrick McHardy | 1 Aug 19:53 2004
Picon

Re: Fw: hfsc and huge set of rules

Tomasz Paszkowski wrote:

>On Fri, Jul 30, 2004 at 12:34:49PM +0200, Patrick McHardy wrote:
>  
>
>>hfsc_destroy_qdisc takes O(n) time wrt. the number of classes,
>>but 5-6 seconds is still long. If all these classes contain inner
>>qdiscs other than the default, I guess removing the classes from
>>dev->qdisc_list in qdisc_destroy takes up most of the time, with
>>n O(n) operations. The __qdisc_destroy rcu callback also calls
>>reset before destroy, I don't know any qdisc where this is really
>>neccessary. Without inner qdiscs, I need to see the script first to
>>judge what's going wrong. Tomasz ?
>>    
>>
>
>http://www.e-wro.pl/~acid/tc.batch.gz. In my opinion it's not the case
>of expensive algorithms, but the number of classes. With this rule set loaded
>(tc -b tc.batch) command:
>
>for i in 'e1.903 e0.930 e0.931 e0.932' ; do
>	tc qdisc del dev ${i} root
>done
>completly freezes machine for about 5-6 seconds.
>  
>
I've done some profiles with your script (on an old kernel without
the lockless loopback patch), qdisc_destroy takes up 89% of the time
when destroying the qdiscs.

(Continue reading)

Patrick McHardy | 1 Aug 19:56 2004
Picon

Re: Fw: hfsc and huge set of rules

devik wrote:

>Also IIRC class lookup is done before each remove. With
>hashing size a few tens of buckets the complexity
>starts to be very near to O(n^2).
>  
>
I think the hash size of HTB, HFSC and CBQ should be increased,
the hash function performs well even with 2^16. With HFSC using
many classes doesn't scale well right now, but with the rbtree patches
it will.

Regards
Patrick

>devik
>
>On Fri, 30 Jul 2004, Patrick McHardy wrote:
>
>  
>
>>David S. Miller wrote:
>>    
>>
>>>Looks like qdisc destruction has some expensive algorithms.
>>>Any quick ideas about the root culprit at least in the hfsc
>>>case?  He says htb does it too.
>>>      
>>>
>>hfsc_destroy_qdisc takes O(n) time wrt. the number of classes,
(Continue reading)


Gmane