* Re: [openib-general] [PATCH v2 1/2] iWARP Connection Manager.
From: Steve Wise @ 2006-06-14 16:11 UTC (permalink / raw)
To: Sean Hefty; +Cc: Andrew Morton, netdev, rdreier, linux-kernel, openib-general
In-Reply-To: <1150235196.17394.91.camel@stevo-desktop>
On Tue, 2006-06-13 at 16:46 -0500, Steve Wise wrote:
> On Tue, 2006-06-13 at 14:36 -0700, Sean Hefty wrote:
> > >> Er...no. It will lose this event. Depending on the event...the carnage
> > >> varies. We'll take a look at this.
> > >>
> > >
> > >This behavior is consistent with the Infiniband CM (see
> > >drivers/infiniband/core/cm.c function cm_recv_handler()). But I think
> > >we should at least log an error because a lost event will usually stall
> > >the rdma connection.
> >
> > I believe that there's a difference here. For the Infiniband CM, an allocation
> > error behaves the same as if the received MAD were lost or dropped. Since MADs
> > are unreliable anyway, it's not so much that an IB CM event gets lost, as it
> > doesn't ever occur. A remote CM should retry the send, which hopefully allows
> > the connection to make forward progress.
> >
>
> hmm. Ok. I see. I misunderstood the code in cm_recv_handler().
>
> Tom and I have been talking about what we can do to not drop the event.
> Stay tuned.
Here's a simple solution that solves the problem:
For any given cm_id, there are a finite (and small) number of
outstanding CM events that can be posted. So we just pre-allocate them
when the cm_id is created and keep them on a free list hanging off of
the cm_id struct. Then the event handler function will pull from this
free list.
The only case where there is any non-finite issue is on the passive
listening cm_id. Each incoming connection request will consume a work
struct. So based on client connects, we could run out of work structs.
However, the CMA has the concept of a backlog, which is defined as the
max number of pending unaccepted connection requests. So we allocate
these work structs based on that number (or a computation based on that
number), and if we run out, we simply drop the incoming connection
request due to backlog overflow (I suggest we log the drop event too).
When a MPA connection request is dropped, the (IETF conforming) MPA
client will eventually time out the connection and the consumer can
retry.
Comments?
^ permalink raw reply
* [PATCH] bcm43xx: use softmac-suggested TX rate
From: Michael Buesch @ 2006-06-14 15:51 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, bcm43xx-dev, Daniel Drake
Hi John,
Sorry, took a little bit longer than expected, but here it is. :)
Please queue for 2.6.18.
--
From: Daniel Drake <dsd@gentoo.org>
Use Softmac-suggested TX ratecode:
ieee80211softmac_suggest_txrate()
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c 2006-06-14 16:53:50.000000000 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c 2006-06-14 17:44:23.000000000 +0200
@@ -296,11 +296,14 @@
u16 control = 0;
u16 wsec_rate = 0;
u16 encrypt_frame;
+ const u16 ftype = WLAN_FC_GET_TYPE(le16_to_cpu(wireless_header->frame_ctl));
+ const int is_mgt = (ftype == IEEE80211_FTYPE_MGMT);
/* Now construct the TX header. */
memset(txhdr, 0, sizeof(*txhdr));
- bitrate = bcm->softmac->txrates.default_rate;
+ bitrate = ieee80211softmac_suggest_txrate(bcm->softmac,
+ is_multicast_ether_addr(wireless_header->addr1), is_mgt);
ofdm_modulation = !(ieee80211_is_cck_rate(bitrate));
fallback_bitrate = bcm43xx_calc_fallback_rate(bitrate);
fallback_ofdm_modulation = !(ieee80211_is_cck_rate(fallback_bitrate));
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
From: Andy Furniss @ 2006-06-14 15:32 UTC (permalink / raw)
To: hadi
Cc: Jesper Dangaard Brouer, hawk, russell-tcatm, lartc, netdev,
Stephen Hemminger
In-Reply-To: <1150286766.5233.15.camel@jzny2>
jamal wrote:
> I have taken linux-kernel off the list.
>
> Russell's site is inaccessible to me (I actually think this is related
> to some DNS issues i may be having) and your masters is too long to
> spend 2 minutes and glean it; so heres a question or two for you:
>
> - Have you tried to do a long-lived session such as a large FTP and
> seen how far off the deviation was? That would provide some interesting
> data point.
> - To be a devil's advocate (and not claim there is no issue), where do
> you draw the line with "overhead"?
Me and many others have run a smilar hack for years, there is also a
userspace project still alive which does the same.
The difference is that without it I would need to sacrifice almost half
my 288kbit atm/dsl showtime bandwidth to be sure of control.
With the modification I can run at 286kbit / 288 and know I will never
have jitter worse than the bitrate latency of a mtu packet. The 286
figure was choses to allow a full buffer to drain/ allow for timer
innaccuracy etc. On a p200 with tsc, 2.6.12 it's never gone over for me
- though talking of timers I notice on my desktop 2.6.16 I gain 2
minutes a day now.
Andy.
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Harald Welte @ 2006-06-14 15:26 UTC (permalink / raw)
To: Erik Mouw
Cc: Daniel Phillips, bidulock, Stephen Hemminger, Sridhar Samudrala,
netdev, linux-kernel
In-Reply-To: <20060614142903.GI11542@harddisk-recovery.com>
[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]
On Wed, Jun 14, 2006 at 04:29:04PM +0200, Erik Mouw wrote:
> On Wed, Jun 14, 2006 at 03:30:22PM +0200, Harald Welte wrote:
> > On Tue, Jun 13, 2006 at 02:12:41PM -0700, Daniel Phillips wrote:
> >
> > > This has the makings of a nice stable internal kernel api. Why do we want
> > > to provide this nice stable internal api to proprietary modules?
> >
> > because there is IMHO legally nothing we can do about it anyway. Use of
> > an industry-standard API that is provided in multiple operating system
> > is one of the clearest idnication of some program _not_ being a
> > derivative work.
>
> IMHO there is no industry-standard API for in-kernel use of sockets.
> There is however one for user space.
it doesn't matter in what space you are. If the API really is similar
enough, then any piece of code (no matter where it was originally
intended to run) will be able to work with any such socket API.
The whole point of this is: Where is the derivation of an existing work?
I can write a program against some BSD socket api somewhere, and I can
easily make it use the proposed in-kernel sockets API. No derivation of
anything that is inside the kernel and GPL licensed.
> (IANAL, etc)
Neither am I, but I'm constantly dealing with legal questions related to
the GPL while running gpl-violations.org.
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
We all know Linux is great...it does infinite loops in 5 seconds. -- Linus
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Refactor Netlink connector?
From: James Morris @ 2006-06-14 15:19 UTC (permalink / raw)
To: jamal
Cc: Stephen Smalley, David S. Miller, netdev, Evgeniy Polyakov,
Thomas Graf
In-Reply-To: <1150288564.5233.31.camel@jzny2>
On Wed, 14 Jun 2006, jamal wrote:
>
> So whats the resolution on this? I actually have some cycles this coming
> weekend that i was hopping to spend updating the doc instead.
Haven't had a chance to look at it since.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
From: Jesper Dangaard Brouer @ 2006-06-14 15:08 UTC (permalink / raw)
To: Phillip Susi; +Cc: netdev, russell-tcatm, hawk
In-Reply-To: <44901CC1.60403@cfl.rr.com>
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]
On Wed, 2006-06-14 at 10:27 -0400, Phillip Susi wrote:
> Jesper Dangaard Brouer wrote:
> > The Linux traffic's control engine inaccurately calculates
> > transmission times for packets sent over ADSL links. For
> > some packet sizes the error rises to over 50%. This occurs
> > because ADSL uses ATM as its link layer transport, and ATM
> > transmits packets in fixed sized 53 byte cells.
> >
>
> I could have sworn that DSL uses its own framing protocol that is
> similar to the frame/superframe structure of HDSL ( T1 ) lines and over
> that you can run ATM or ethernet. Or is it typically ethernet -> ATM ->
> HDSL?
Nope, not according to the ADSL standards G.992.1 and G.992.2.
> In any case, why does the kernel care about the exact time that the IP
> packet has been received and reassembled on the headend?
I think you have misunderstood what the rate table does...
(There is an explaination in the thesis page 57 section 6.1.2)
http://www.adsl-optimizer.dk/thesis/
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network developer
Cand. Scient Datalog / MSc.
Author of http://adsl-optimizer.dk
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Jeff Garzik @ 2006-06-14 15:03 UTC (permalink / raw)
To: Grant Grundler; +Cc: Valerie Henson, Andrew Morton, netdev
In-Reply-To: <20060614044412.GA30552@colo.lackof.org>
Grant Grundler wrote:
> On Tue, Jun 13, 2006 at 08:33:22PM -0400, Jeff Garzik wrote:
>> Grant Grundler wrote:
>>> o tulip_stop_rxtx() has to be called _after_ free_irq().
>>> ie. v2 patch didn't fix the original race condition
>>> and when under test, dies about as fast as the original code.
>> You made the race window smaller, but it's still there. The chip's DMA
>> engines should be stopped before you unregister the interrupt handler.
>
> Switching the order to be:
> tulip_stop_rxtx(tp); /* Stop DMA */
> free_irq (dev->irq, dev); /* no more races after this */
>
> still leaves us open to IRQs being delivered _after_ we've stopped DMA.
Correct. And that is the preferred, natural, logical, obvious order:
1) Turn things off.
2) Wait for activity to cease.
> That in turn allows the interrupt handler to re-enable DMA again.
Then that would be a problem to solve... Some interrupt handlers will
test netif_running() or a driver-specific shutting-down flag,
specifically to avoid such behaviors.
Jeff
^ permalink raw reply
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Grant Grundler @ 2006-06-14 14:54 UTC (permalink / raw)
To: Kyle McMartin
Cc: Grant Grundler, Jeff Garzik, Valerie Henson, Andrew Morton,
netdev
In-Reply-To: <20060614130506.GA8556@skunkworks.cabal.ca>
On Wed, Jun 14, 2006 at 09:05:06AM -0400, Kyle McMartin wrote:
> I think the correct sequence would be:
>
> reset tulip interrupt mask
> flush posted write
>
> synchronize irq /* make sure we got 'em all */
> tulip_stop_rxtx /* turn off dma */
> free irq /* bye bye */
>
> The synchronize irq guarantees we shouldn't see another irq
> generated by the card because it was held up somewhere.
Kyle,
syncronize_irq() only guarantees currently executing interrupt handler
completes before handing control back to the caller.
It does not guarantee IRQ signals still inflight are "flushed".
Remember that IRQ lines are a "sideband" signal and not subject
to PCI data ordering rules.
thanks,
grant
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Erik Mouw @ 2006-06-14 14:29 UTC (permalink / raw)
To: Harald Welte
Cc: Daniel Phillips, bidulock, Stephen Hemminger, Sridhar Samudrala,
netdev, linux-kernel
In-Reply-To: <20060614133022.GU11863@sunbeam.de.gnumonks.org>
On Wed, Jun 14, 2006 at 03:30:22PM +0200, Harald Welte wrote:
> On Tue, Jun 13, 2006 at 02:12:41PM -0700, Daniel Phillips wrote:
>
> > This has the makings of a nice stable internal kernel api. Why do we want
> > to provide this nice stable internal api to proprietary modules?
>
> because there is IMHO legally nothing we can do about it anyway. Use of
> an industry-standard API that is provided in multiple operating system
> is one of the clearest idnication of some program _not_ being a
> derivative work.
IMHO there is no industry-standard API for in-kernel use of sockets.
There is however one for user space.
Erik
(IANAL, etc)
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
From: Phillip Susi @ 2006-06-14 14:27 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Stephen Hemminger, Jamal Hadi Salim, netdev, lartc, russell-tcatm,
hawk, linux-kernel
In-Reply-To: <1150278004.26181.35.camel@localhost.localdomain>
Jesper Dangaard Brouer wrote:
> The Linux traffic's control engine inaccurately calculates
> transmission times for packets sent over ADSL links. For
> some packet sizes the error rises to over 50%. This occurs
> because ADSL uses ATM as its link layer transport, and ATM
> transmits packets in fixed sized 53 byte cells.
>
I could have sworn that DSL uses its own framing protocol that is
similar to the frame/superframe structure of HDSL ( T1 ) lines and over
that you can run ATM or ethernet. Or is it typically ethernet -> ATM ->
HDSL?
In any case, why does the kernel care about the exact time that the IP
packet has been received and reassembled on the headend?
^ permalink raw reply
* Re: http://bugzilla.kernel.org/show_bug.cgi?id=6197
From: Patrick McHardy @ 2006-06-14 14:04 UTC (permalink / raw)
To: Michael Tokarev; +Cc: netdev
In-Reply-To: <448F304A.2020808@tls.msk.ru>
Michael Tokarev wrote:
> Patrick McHardy wrote:
> []
>
>>He patched his kernel with the IMQ device, which is known to cause all
>>kinds of weird problems.
>
>
> Wich problems? Known to whom?
Known to me (who wrote the original implementation of the current IMQ
device) and numerous people who were hit by them. IIRC it does some
invalid skb refcounting hacks which result in crashes in certain
scenarios - but I don't remeber the exact details.
> I was considering using imq for our needs (not done yet), and from the
> FAQ at http://www.linuximq.net/faq.html (item #3, "Is it stable?") it
> seems there's no problems except of gre tunnels and locally generated
> traffic...
>
> Googling for "imq linux problem" shows usual pile of various user
> support questions (how to configure.. what did I do wrong.. etc),
> but nothing relevant.
The lartc list had lots of reports of crashes. I guess "imq crash" or
"imq oops" will give better results.
> So... I'm curious whenever the claim on linuximq.net site about the
> stability is true, or there in fact are some real issue...
>From what I know these problems haven't been fixed. Current kernels
include Jamal's tc actions and the ifb-Device, which obsolete IMQ
anyway.
^ permalink raw reply
* Offering presents for more routing tables!
From: Ben Greear @ 2006-06-14 13:45 UTC (permalink / raw)
To: NetDev
I've asked for this feature several years ago and evidently
it is not trivial to increase the number of routing tables.
But, perhaps someone now has time & inclination?
I would like to have more (a few thousand) routing tables
available in the kernel so that I can use a routing table for
each of my many VLANs. Currently, the netlink protocol only
specifies an 8-bit id for the routing table:
http://www.faqs.org/rfcs/rfc3549.html Section 3.1.1
so a new netlink message would need to be created and the 'ip' tool
updated. I think at least a 16-bit identifier should be used,
possibly a full 32 bits so we don't have to revisit this again for
a while!
The kernel itself would also need to be modified so that it can
have more routing tables. I realize most people don't need a
large number of tables, so the maximum number should be configured
at either compile time or run time.
If I remember right, there are certain tables (253 - 255) that
are currently special in the kernel. For complete backwards compatibility,
this hole would probably have to remain as it is, with the new
tables starting at 256.
I would be willing to help test any resulting patches, and can
also offer bribes of money, hardware, beer, etc.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Harald Welte @ 2006-06-14 13:30 UTC (permalink / raw)
To: Daniel Phillips
Cc: bidulock, Stephen Hemminger, Sridhar Samudrala, netdev,
linux-kernel
In-Reply-To: <448F2A49.5020809@google.com>
[-- Attachment #1: Type: text/plain, Size: 955 bytes --]
On Tue, Jun 13, 2006 at 02:12:41PM -0700, Daniel Phillips wrote:
> This has the makings of a nice stable internal kernel api. Why do we want
> to provide this nice stable internal api to proprietary modules?
because there is IMHO legally nothing we can do about it anyway. Use of
an industry-standard API that is provided in multiple operating system
is one of the clearest idnication of some program _not_ being a
derivative work.
Whether we like it or not, it doesn't really matter if we export them
GPL-only or not. Anybody using those scoket API calls will be having an
easy time arguing in favor of non-derivative work.
The GPL doesn't extend beyon what copyright law allows you to do...
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
We all know Linux is great...it does infinite loops in 5 seconds. -- Linus
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Kyle McMartin @ 2006-06-14 13:05 UTC (permalink / raw)
To: Grant Grundler; +Cc: Jeff Garzik, Valerie Henson, Andrew Morton, netdev
In-Reply-To: <20060614044412.GA30552@colo.lackof.org>
On Tue, Jun 13, 2006 at 10:44:12PM -0600, Grant Grundler wrote:
> On Tue, Jun 13, 2006 at 08:33:22PM -0400, Jeff Garzik wrote:
> > Grant Grundler wrote:
> > >o tulip_stop_rxtx() has to be called _after_ free_irq().
> > > ie. v2 patch didn't fix the original race condition
> > > and when under test, dies about as fast as the original code.
> >
> > You made the race window smaller, but it's still there. The chip's DMA
> > engines should be stopped before you unregister the interrupt handler.
>
> Switching the order to be:
> tulip_stop_rxtx(tp); /* Stop DMA */
> free_irq (dev->irq, dev); /* no more races after this */
>
I think the correct sequence would be:
reset tulip interrupt mask
flush posted write
synchronize irq /* make sure we got 'em all */
tulip_stop_rxtx /* turn off dma */
free irq /* bye bye */
The synchronize irq guarantees we shouldn't see another irq
generated by the card because it was held up somewhere.
Cheers,
Kyle M.
^ permalink raw reply
* Re: driver for pptp
From: Harald Welte @ 2006-06-14 13:18 UTC (permalink / raw)
To: xeb; +Cc: netdev
In-Reply-To: <E1FmQDD-0005kY-00.xeb-mail-ru@f51.mail.ru>
[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]
On Sat, Jun 03, 2006 at 11:06:19AM +0400, xeb@mail.ru wrote:
> I have developed the driver for Point-to-Point Tunneling Protocol (PPTP).
great news. something that I always thought of a nice-to-have.
> I have published the project on http://accel-pptp.sourceforge.net/
Please don't expect Linux Kernel networking developers to actually go to
sourceforge download and extract code that you want to have
reviewed/submitted.
Please read Documentation/SubmittingPatches (and CodingStyle) and submit
your kernel patch to netdev.
> Hope this driver will go to a kernel tree and will make linux more productive.
not without you pushing it actively and getting through review cycles
(which I hope you will!).
Some initial comments:
1) why wasn't it possible to use the PPPoX infrastructure of the kernel
which is already being used by PPPoE ? Or at least model it somehow
similar to the existing PPPoE/PPPoX infrastructure?
2) why are you using a timer for asynchronous processing of GRE frames?
First of all, why does it have to happen asynchronously at all?
Secondly, why using a timer when there's nothing time related (or do
I miss something)? If deferred, out-of-context execution is
required, there are other primitives such as tasklets.
3) you conflict with the ip_gre.c genric GRE encapsulation driver. this
is because both want to reigster a proto handler for GRE. Ideally,
there needs to be another demultiplex between the GRE protocl and its
users. The code registered for GRE would look at the packet and
determine whether e.g. it is a PPTP GRE packet and then pass it on to
the pptp module.
4) your code doesn't look nonlinear skb clean
5) why did you chose to implement /dev/pptp rather than a socket family
like the existing pppox/pppoe code?
6) lots of codingstyle issues
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
We all know Linux is great...it does infinite loops in 5 seconds. -- Linus
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] NET: Accurate packet scheduling for ATM/ADSL (userspace)
From: Jesper Dangaard Brouer @ 2006-06-14 13:18 UTC (permalink / raw)
To: Alan Cox
Cc: Stephen Hemminger, Jamal Hadi Salim, netdev, lartc, russell-tcatm,
hawk, linux-kernel, hawk
In-Reply-To: <1150282625.3490.23.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]
On Wed, 2006-06-14 at 11:57 +0100, Alan Cox wrote:
> Ar Mer, 2006-06-14 am 11:40 +0200, ysgrifennodd Jesper Dangaard Brouer:
> > option to calculate traffic transmission times (rate table)
> > over all ATM links, including ADSL, with perfect accuracy.
>
> The other problem I see with this code is it is very tightly tied to ATM
> cell sizes, not to solving the generic question of packetisation.
Well, we did consider to do so, but we though that it would be harder to
get it into the kernel.
Actually thats the reason for the defines:
#define ATM_CELL_SIZE 53
#define ATM_CELL_PAYLOAD 48
Changing these should should make it possible to adapt to any other SAR
(Segment And Reasembly) link layer.
> I'm
> not sure if that matters but for modern processors I'm also sceptical
> that the clever computation is actually any faster than just doing the
> maths, especially if something cache intensive is also running.
I guess you are refering to the rate table lookup system, that is based
upon array lookups. I do think that the rate table array lookup system
has been outdated, as memory access is the bottleneck on modern CPUs.
But its design by Alexey for a long time ago where the hardware
restrictions were different. It also avoids floting point operations in
the kernel.
Thanks for your comments.
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network developer
Cand. Scient Datalog / MSc.
Author of http://adsl-optimizer.dk
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Problems with xfrm (IPSec) and multicast
From: Roar Bjørgum Rotvik @ 2006-06-14 13:09 UTC (permalink / raw)
To: netdev
Hi,
I have configured two Linux PC's to use IPSec to encrypt some mcast traffic, using "ip
xfrm". Each PC has two network cards, one connected to a LAN (unencrypted side, also
called red side) and one connected to the other node (encrypted side, also called black side).
Currently the setup uses static keys in the SA entries, so IKE is not a problem.
|<-- RED side -->|<- BLACK network ->|<-- RED side -->|
+-------+ +---------+ +---------+ +-------+
| LAN A +---+ IPSEC-A +-----------+ IPSEC-B +---+ LAN B |
+-------+ +---------+ +---------+ +-------+
10.0.10.0/24 192.168.0.0/24 10.0.20.0/24
Configuration:
Kernel tested: Linux-2.6.16.13 + 2.6.17-rc4
LAN A: 10.0.10.0/24
LAN B: 10.0.20.0/24
IPSEC-A: RED IP: 10.0.10.1, BLACK IP: 192.168.0.1
IPSEC-B: RED IP: 10.0.20.1, BLACK IP: 192.168.0.2
RED mcast group used: 239.192.20.1
BLACK mcast group used: 239.192.10.1
IPSEC-A SA and SP entries:
[root@ipsec-a ~]# ip xfrm state
src 192.168.0.1 dst 239.192.10.1
proto esp spi 0x00000001 reqid 0 mode tunnel
replay-window 4
auth sha1 0x00000000010000000002000000000301
enc aes 0x000000000000000000000000000000000000000000000001
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
[root@ipsec-a ~]# ip xfrm policy
src 0.0.0.0/0 dst 239.192.20.1/32
dir in priority 2147483648
tmpl src 192.168.0.1 dst 239.192.10.1
proto esp reqid 0 mode tunnel
src 10.0.10.0/24 dst 239.192.20.1/32
dir out priority 2147483648
tmpl src 192.168.0.1 dst 239.192.10.1
proto esp reqid 0 mode tunnel
src 0.0.0.0/0 dst 239.192.20.1/32
dir fwd priority 2147483648
tmpl src 192.168.0.1 dst 239.192.10.1
proto esp reqid 0 mode tunnel
(The entries for IPSEC-B is similar, but the address 192.168.0.1 is changed to the IPSEC-B
BLACK IP 192.168.0.2).
And I have a small userspace app that opens a socket and bind to port 4500 and issue
setsockopt (fd, SOL_UDP, UDP_ENCAP) so that the kernel will accept UDP encap ESP packets.
When I send multicast traffic from IPSEC-A (bound to the RED interface 10.0.10.1) to mcast
group 239.192.20.1, the traffic matches the out SP entry and is encrypted according to the
SA entry and sent as UDP encap ESP to mcast group 239.192.10.1 on the BLACK network.
On IPSEC-B the UDP encap ESP packet is decrypted and is visible for userspace processes.
So far so good.
But then I start sending similar mcast traffic the other way, but from IPSEC-B (bound to
IPSEC-B RED IP 10.0.20.1). This traffic is also encrypted and sent to IPSEC-A.
But this packet is not decrypted at IPSEC-A, it seems to disappear. The IP and UDP SNMP
counters increase for the received UDP encap ESP packet, but I cannot see what happens to
the packet after the UDP layer. Seems like it is dropped somewhere in XFRM?
By sending some more packets from IPSEC-B (roughly 5-8 more packets), these packets
suddenly starts to be decrypted at IPSEC-A and all is well. Until I start traffic the
other way around again, when the same problem occurs at IPSEC-B.
So I cannot make encrypted multicast traffic to flow both ways at the same time, and has
no clue as to why the first packets after changing direction is dropped somewhere.
Anyone have a clue to this observed problem with linux xfrm and multicast or a better
solution for encrypted multicast on linux 2.6.x?
Any help with this is appreciated and more info (tcpdump, snmp stats and so on) can be
obtained if needed.
--
Roar Bjørgum Rotvik
^ permalink raw reply
* Re: netif_tx_disable and lockless TX
From: jamal @ 2006-06-14 12:52 UTC (permalink / raw)
To: Robert Olsson
Cc: Andi Kleen, David Miller, mchan, jgarzik, netdev, Herbert Xu
In-Reply-To: <17533.55270.172654.98522@robur.slu.se>
On Wed, 2006-31-05 at 19:52 +0200, Robert Olsson wrote:
> jamal writes:
>
> > Latency-wise: TX completion interrupt provides the best latency.
> > Processing in the poll() -aka softirq- was almost close to the hardirq
> > variant. So if you can make things run in a softirq such as transmit
> > one, then the numbers will likely stay the same.
>
> I don't remember we tried tasklet for TX a la Herbert's suggestion but we
> used use tasklets for controlling RX processing to avoid hardirq livelock
> in pre-NAPI versions.
>
Hrm - it may have been a private thing i did then. I could swear we did
that experiment together ...
Perhaps Herbert's motivation was not really to optimize but rather to
get something unstuck in the transmit path state machine maybe in a
context of netconsole? The conditions for which that tasklet would even
run require a CPU collision to the transmit. Sorry, I didnt quiet follow
the motivation/discussion that ended in that patch.
> Had variants of tulip driver with both TX cleaning at ->poll and TX
> cleaning at hardirq and didn't see any performance difference. The
> ->poll was much cleaner but we kept Alexey's original work for tulip.
>
It certainly is cleaner - but i do recall the hardirq variant had better
latency much observable under high packet rates aka small packets.
> > Sorry, I havent been following discussions on netchannels[1] so i am not
> > qualified to comment on the "replacement" part Dave mentioned earlier.
> > What I can say is the tx processing doesnt have to be part of the NAPI
> > poll() and still use hardirq.
>
> Yes true but I see TX numbers with newer boards (wire rate small pakets)
> with cleaing in ->poll. Also now linux is very safe in network "overload"
> situations. Moving work to hardirq may change that.
>
Oh, I am not suggesting a change - i am a lot more conservative than
that ;-> these areas are delicate (not code-delicate Acme ;->) but
rather what seems obvious requires a lot of experimental results first.
Robert, your transmit results Intel or AMD based?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
From: Jesper Dangaard Brouer @ 2006-06-14 12:55 UTC (permalink / raw)
To: hadi; +Cc: hawk, russell-tcatm, lartc, netdev, Stephen Hemminger
In-Reply-To: <1150286766.5233.15.camel@jzny2>
[-- Attachment #1: Type: text/plain, Size: 4519 bytes --]
On Wed, 2006-06-14 at 08:06 -0400, jamal wrote:
> Russell's site is inaccessible to me (I actually think this is related
> to some DNS issues i may be having)
Strange, I have access to Russell's site. Maybe its his redirect
feature that confuses your browser, try:
http://ace-host.stuart.id.au/russell/files/tc/tc-atm/
> and your masters is too long to
> spend 2 minutes and glean it; so heres a question or two for you:
Yes, I is quite long and very detailed. But it worth reading (... says
the author him self ;-))
> - Have you tried to do a long-lived session such as a large FTP and
> seen how far off the deviation was? That would provide some interesting
> data point.
The deviation can be calculated. The impact is of cause small for large
packets. But the argument that bulk TCP transfers is not as badly
affected, is wrong because all the TCP ACK packets gets maximum penalty.
On an ADSL link with more than 8 bytes overhead, a 40 bytes TCP ACK will
use more that one ATM frame, causing 2 ATM frames to be send that
consumes 106 bytes, eg. 62% overhead. On a small upstream ADSL line
that hurts! (See thesis page 53, table 5.3 "Overhead summary").
> - To be a devil's advocate (and not claim there is no issue), where do
> you draw the line with "overhead"?
> Example the smallest ethernet packet is 64 bytes of which 14 bytes are
> ethernet headers ("overhead" for IP) - and this is not counting CRC etc.
> If you were to set an MTU of say 64 bytes and tried to do a http or ftp,
> how accurate do you think the calculation would be? I would think not
> very different.
I do think we handle this situation, but I'm not quite sure that I fully
understand the question (sorry).
> Does it matter if it is accurate on the majority of the cases?
> - For further reflection: Have you considered the case where the rate
> table has already been considered on some link speed in user space and
> then somewhere post-config the physical link speed changes? This would
> happen in the case where ethernet AN is involved and the partner makes
> some changes (use ethtool).
>
> I would say the last bullet is a more interesting problem than a corner
> case of some link layer technology that has high overhead.
We only claim to do magic on ATM/ADSL links... nothing else ;-)
> Your work would be more interesting if it was generic for many link
> layers instead of just ATM.
Well, we did consider to do so, but we though that it would be harder to
get it into the kernel.
Actually thats the reason for the defines:
#define ATM_CELL_SIZE 53
#define ATM_CELL_PAYLOAD 48
Changing these should should make it possible to adapt to any other SAR
(Segment And Reasembly) link layer.
> On Wed, 2006-14-06 at 11:40 +0200, Jesper Dangaard Brouer wrote:
> > The Linux traffic's control engine inaccurately calculates
> > transmission times for packets sent over ADSL links. For
> > some packet sizes the error rises to over 50%. This occurs
> > because ADSL uses ATM as its link layer transport, and ATM
> > transmits packets in fixed sized 53 byte cells.
> >
> > The following patches to iproute2 and the kernel add an
> > option to calculate traffic transmission times over all
> > ATM links, including ADSL, with perfect accuracy.
> >
> > A longer presentation of the patch, its rational, what it
> > does and how to use it can be found here:
> > http://www.stuart.id.au/russell/files/tc/tc-atm/
> >
> > A earlier version of the patch, and a _detailed_ empirical
> > investigation of its effects can be found here:
> > http://www.adsl-optimizer.dk/
> >
> > The patches are both backwards and forwards compatible.
> > This means unpatched kernels will work with a patched
> > version of iproute2, and an unpatched iproute2 will work
> > on patches kernels.
> >
> >
> > This is a combined effort of Jesper Brouer and Russell Stuart,
> > to get these patches into the upstream kernel.
> >
> > Let the discussion start about what we need to change to get this
> > upstream?
> >
> > We see this as a feature enhancement, as thus hope that it can be
> > queued in davem's net-2.6.18.git tree.
> >
> > ---
> > Regards,
> > Jesper Brouer & Russell Stuart.
> >
>
Thanks for your comments :-)
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network developer
Cand. Scient Datalog / MSc.
Author of http://adsl-optimizer.dk
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Refactor Netlink connector?
From: jamal @ 2006-06-14 12:36 UTC (permalink / raw)
To: James Morris
Cc: Stephen Smalley, David S. Miller, netdev, Evgeniy Polyakov,
Thomas Graf
In-Reply-To: <Pine.LNX.4.64.0606011022450.16136@d.namei>
So whats the resolution on this? I actually have some cycles this coming
weekend that i was hopping to spend updating the doc instead.
cheers,
jamal
On Thu, 2006-01-06 at 10:24 -0400, James Morris wrote:
> On Thu, 1 Jun 2006, Thomas Graf wrote:
>
> > It shouldn't be hard to split what is implemented in nlmsg_route_perms[]
> > for NETLINK_ROUTE into the definitions of the generic netlink
> > operations, could look like this:
> >
> > struct genl_ops some_op = {
> > [...]
> > .perm = NETLINK_GENERIC_SOCKET__NLMSG_READ,
> > };
>
> We wouldn't need the socket class outside of SELinux, just the perm, so
> something like:
>
> NL_PERM_READ
>
> > int genl_peek_cmd(struct nlmsghdr *nlh)
> > {
> > struct genlmsghdr *hdr = nlmsg_data(nlh);
> >
> > if (nlh->nlmsglen < nlmsg_msg_sizeo(GENL_HDRLEN))
> > return -EINVAL;
> >
> > return hdr->cmd;
> > }
>
> Unless I'm mistaken, people are already multiplexing commands inside genl
> commands (and if so, why even bother with registerable ops?).
>
>
> I'll look at it in more detail soon.
>
>
^ permalink raw reply
* Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
From: jamal @ 2006-06-14 12:06 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: hawk, russell-tcatm, lartc, netdev, Stephen Hemminger
In-Reply-To: <1150278004.26181.35.camel@localhost.localdomain>
I have taken linux-kernel off the list.
Russell's site is inaccessible to me (I actually think this is related
to some DNS issues i may be having) and your masters is too long to
spend 2 minutes and glean it; so heres a question or two for you:
- Have you tried to do a long-lived session such as a large FTP and
seen how far off the deviation was? That would provide some interesting
data point.
- To be a devil's advocate (and not claim there is no issue), where do
you draw the line with "overhead"?
Example the smallest ethernet packet is 64 bytes of which 14 bytes are
ethernet headers ("overhead" for IP) - and this is not counting CRC etc.
If you were to set an MTU of say 64 bytes and tried to do a http or ftp,
how accurate do you think the calculation would be? I would think not
very different.
Does it matter if it is accurate on the majority of the cases?
- For further reflection: Have you considered the case where the rate
table has already been considered on some link speed in user space and
then somewhere post-config the physical link speed changes? This would
happen in the case where ethernet AN is involved and the partner makes
some changes (use ethtool).
I would say the last bullet is a more interesting problem than a corner
case of some link layer technology that has high overhead.
Your work would be more interesting if it was generic for many link
layers instead of just ATM.
cheers,
jamal
On Wed, 2006-14-06 at 11:40 +0200, Jesper Dangaard Brouer wrote:
> The Linux traffic's control engine inaccurately calculates
> transmission times for packets sent over ADSL links. For
> some packet sizes the error rises to over 50%. This occurs
> because ADSL uses ATM as its link layer transport, and ATM
> transmits packets in fixed sized 53 byte cells.
>
> The following patches to iproute2 and the kernel add an
> option to calculate traffic transmission times over all
> ATM links, including ADSL, with perfect accuracy.
>
> A longer presentation of the patch, its rational, what it
> does and how to use it can be found here:
> http://www.stuart.id.au/russell/files/tc/tc-atm/
>
> A earlier version of the patch, and a _detailed_ empirical
> investigation of its effects can be found here:
> http://www.adsl-optimizer.dk/
>
> The patches are both backwards and forwards compatible.
> This means unpatched kernels will work with a patched
> version of iproute2, and an unpatched iproute2 will work
> on patches kernels.
>
>
> This is a combined effort of Jesper Brouer and Russell Stuart,
> to get these patches into the upstream kernel.
>
> Let the discussion start about what we need to change to get this
> upstream?
>
> We see this as a feature enhancement, as thus hope that it can be
> queued in davem's net-2.6.18.git tree.
>
> ---
> Regards,
> Jesper Brouer & Russell Stuart.
>
^ permalink raw reply
* Re: Remove Prism II support from Orinoco
From: Jiri Benc @ 2006-06-14 11:53 UTC (permalink / raw)
To: Faidon Liambotis; +Cc: netdev
In-Reply-To: <448E3F80.5050103@cube.gr>
On Tue, 13 Jun 2006 07:30:56 +0300, Faidon Liambotis wrote:
> Unfortunately, that workaround doesn't work so well when you want to
> have the ability to plug real orinoco (hermes) cards to your computer...
> In other words and unless I'm missing something, there isn't currently a
> way to have a Hermes card and a Prism II card both plugged in and working.
Do you know about /sys/bus/pci/drivers/*/bind and unbind?
http://lwn.net/Articles/143397/
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Brian F. G. Bidulock @ 2006-06-14 10:54 UTC (permalink / raw)
To: Alan Cox; +Cc: netdev, linux-kernel
In-Reply-To: <1150281823.3490.14.camel@localhost.localdomain>
Alan,
On Wed, 14 Jun 2006, Alan Cox wrote:
> It isn't "policy" its called copyright law.
I know that I said I'd shut up, but I missed in TRIPS where it said
that symbols must be EXPORT_SYMBOL_GPL... Could you point that out?
(Just kidding.)
> You don't seem to understand copyright law either. The GPL like all
> copyright licenses deals with the right to make copies and to create and
> control derivative works. It's not "defeated" by four lines of code.
The 3 or 4 lines of code that I wrote as an original expression before
the patch was submitted.
> Is that a confession ;)
No, just a declaration: the code in question was released under GPL
Version 2.
> Copyright is not about novelty, you have it confused with the
> theoretical (not actual) role of patents. Wrong kind of intellectual
> monopoly right.
Yes, perhaps I should have said "original" instead of "novel". The patch
is not "original" as it was predated by equivalent (machine translatable)
original expressions.
^ permalink raw reply
* Re: [PATCH 2/2] NET: Accurate packet scheduling for ATM/ADSL (userspace)
From: Alan Cox @ 2006-06-14 10:57 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Stephen Hemminger, Jamal Hadi Salim, netdev, lartc, russell-tcatm,
hawk, linux-kernel
In-Reply-To: <1150278040.26181.37.camel@localhost.localdomain>
Ar Mer, 2006-06-14 am 11:40 +0200, ysgrifennodd Jesper Dangaard Brouer:
> option to calculate traffic transmission times (rate table)
> over all ATM links, including ADSL, with perfect accuracy.
<Pedant>
Only if the lowest level is encoded in a time linear manner. If you are
using NRZ, NRZI etc at the bottom level then you may still be out...
</Pedant>
The other problem I see with this code is it is very tightly tied to ATM
cell sizes, not to solving the generic question of packetisation. I'm
not sure if that matters but for modern processors I'm also sceptical
that the clever computation is actually any faster than just doing the
maths, especially if something cache intensive is also running.
Alan
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Theodore Tso @ 2006-06-14 10:36 UTC (permalink / raw)
To: Chase Venters
Cc: bidulock, Daniel Phillips, Stephen Hemminger, Sridhar Samudrala,
netdev, linux-kernel
In-Reply-To: <200606131953.42002.chase.venters@clientec.com>
On Tue, Jun 13, 2006 at 07:53:19PM -0500, Chase Venters wrote:
> > It is the lack of an ABI that is most frustrating to these users.
>
> And the presence of an ABI would be _very_ frustrating to core
> developers. Not only would these people suffer, everyone would --
> developer time would be wasted dealing with cruft, and forward
> progress would be slowed.
Note that just because an interface is EXPORT_SYMBOL doesn't mean that
the interface is guaranteed to be stable. So folks who are aruging
that an interface shouldn't be usable by non-GPL applications because
we are therefore guaranteeing a stable API are making an unwarranted
assumption.
- Ted
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox