headers
jamal | 1 Mar 2003 04:18
Picon
Picon

Re: anyone ever done multicast AF_UNIX sockets?


On Fri, 28 Feb 2003, Chris Friesen wrote:

>  From lmbench local communication tests:
>
> This is a multiproc 1GHz G4
> Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
>                          ctxsw       UNIX         UDP         TCP conn
> --------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
> pcary0z0. Linux 2.4.18- 0.600 3.756 6.58  10.2  26.4  13.8  36.9 599K
> pcary0z0. Linux 2.4.18- 0.590 3.766 6.43  10.1  26.7  13.9  37.2 59.1
>
>
> This is a 400MHz uniproc G4
> Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
>                          ctxsw       UNIX         UDP         TCP conn
> --------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
> zcarm0pd. Linux 2.2.17- 1.710 9.888 21.3  26.4  59.4  43.0 105.4 146.
> zcarm0pd. Linux 2.2.17- 1.740 9.866 22.2  26.3  60.4  43.1 106.7 147.
>
> This is a 1.8GHz P4
> Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
>                          ctxsw       UNIX         UDP         TCP conn
> --------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
> pcard0ks. Linux 2.4.18- 1.740  10.4 15.9  20.1  33.1  23.5  44.3 72.7
> pcard0ks. Linux 2.4.18-        10.3 16.1  19.8  36.3  22.8  43.6 74.1
> pcard0ks. Linux 2.4.18- 1.560  10.6 16.0  23.4  38.1  36.1  44.6 77.4
>
>
>  From these numbers, UDP has 18%-44% higher latency than AF_UNIX, with
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Friesen | 2 Mar 2003 07:03

Re: anyone ever done multicast AF_UNIX sockets?

jamal wrote:
> Did you also measure throughput?

No.  lmbench doesn't appear to test UDP socket local throughput.

> You are overlooking the flexibility that already exists in IP based
> transports as an advantage; the fact that you can make them
> distributed instead of localized with a simple addressing change
> is a very powerful abstraction.

True.  On the other hand, the same could be said about unicast IP 
sockets vs unix sockets.  Unix sockets exist for a reason, and I'm 
simply proposing to extend them.

>>From
>>userspace, multicast unix would be *simple* to use, as in totally
>>transparent.

> You could implement the abstraction in user space as a library today by
> having some server that muxes to several registered clients.

This is what we have now, though with a suboptimal solution (we 
inherited it from another group).  The disadvantage with this is that it 
adds a send/schedule/receive iteration.  If you have a small number of 
listeners this can have a large effect percentage-wise on your messaging 
cost.  The kernel approach also cuts the number of syscalls required by 
a factor of two compared to the server-based approach.

> So whats the addressing scheme for multicast unix? Would it be a
> reserved path?
(Continue reading)

Permalink | Reply | 1 comment |
headers
jamal | 2 Mar 2003 15:11
Picon
Picon

Re: anyone ever done multicast AF_UNIX sockets?


On Sun, 2 Mar 2003, Chris Friesen wrote:

> jamal wrote:
> > Did you also measure throughput?
>
> No.  lmbench doesn't appear to test UDP socket local throughput.

I think you need to collect all data if you are trying to show
improvements.

>
> > You are overlooking the flexibility that already exists in IP based
> > transports as an advantage; the fact that you can make them
> > distributed instead of localized with a simple addressing change
> > is a very powerful abstraction.
>
> True.  On the other hand, the same could be said about unicast IP
> sockets vs unix sockets.  Unix sockets exist for a reason, and I'm
> simply proposing to extend them.
>

You are treading into areas where unix sockets make less sense compared to
sockets. Good design rules (should actually read "lazy design
rules") ometimes you gotta move to a round peg instead of trying to make
the square one round.

> > You could implement the abstraction in user space as a library today by
> > having some server that muxes to several registered clients.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Zheng Jianping | 3 Mar 2003 08:49
Picon

How to set IPv6 router alert option

Hi,

I want to send a packet(MLD query message) with IPv6 router alert option by
socket.
After creating a ICMPv6 socket, how to send a MLD query message packet by
the created socket.

Thanks,
Zheng Jianping

----------------------------------------------------------------------------
---------------------------
Multimedia Communication & Network Engneering Research Center
Institue of Software, Chiese Academy of Sciences

Email: zjp <at> iscas.ac.cn
Tel:     6255,5523
Permalink | Reply | 0 comments |
headers
David S. Miller | 3 Mar 2003 09:44
Picon
Favicon

Re: [PATCH] subset of RFC2553

   From: Bruce Allan <bwa <at> us.ibm.com>
   Date: 24 Feb 2003 09:54:57 -0800

   On Fri, 2003-02-21 at 23:26, David S. Miller wrote:
   > 
   > Bruce, while applying this I noticed that in6addr_{any,loopback}
   > are not exported by modules.
   > 
   > Please send me a small patch to add the exports if this will be
   > needed by SCTP and friends.

   Doh!  Sorry, here (see below) it is against 2.5.59.

Applied, thanks.
Permalink | Reply | 0 comments |
headers
David S. Miller | 3 Mar 2003 09:54
Picon
Favicon

Re: [PATCH] IPv6: Privacy Extensions for Stateless Address Autoconfiguration in IPv6

   From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji <at> linux-ipv6.org>
   Date: Wed, 26 Feb 2003 00:41:55 +0900 (JST)

   Well, I've found a bug that a temporary addresses were not
   re-generated properly.  Here's the patch for linux-2.5.63.

Fix applied, thanks.
Permalink | Reply | 0 comments |
headers
David S. Miller | 3 Mar 2003 10:28
Picon
Favicon

Re: PATCH: IPSec not using padding when Null Encryption

   From: latten <at> austin.ibm.com
   Date: Thu, 27 Feb 2003 15:29:19 -0600

   Ok, anyway, this fix just pretty much makes sure that
   when Null Encryption or any algorithm with a blocksize less
   than 4 is used, that the ciphertext, any padding, and next-header
   and pad-length fields terminate on a 4-byte boundary.
   I have tested it. Please let me know if all is well. 

Applied, thanks.
Permalink | Reply | 0 comments |
headers
David S. Miller | 3 Mar 2003 10:30
Picon
Favicon

Re: [PATCH] Use C99 initializers in net/ipv6

   From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji <at> linux-ipv6.org>
   Date: Fri, 28 Feb 2003 06:59:44 +0900 (JST)

   This convers net/ipv6/{addrconf,route,sit}.c files to use C99
   initializers.  We don't touch net/ipv6/exthdrs.c for now because
   it will conflicts with our patch for IPsec.

Applied, thanks.
Permalink | Reply | 0 comments |
headers
David S. Miller | 3 Mar 2003 10:34
Picon
Favicon

Re: IPSec: setkey -DP freezes machine

   From: James Morris <jmorris <at> intercode.com.au>
   Date: Sat, 1 Mar 2003 03:01:04 +1100 (EST)

   Alternatively, a family parameter could be added to the compile_policy() 
   operation, but this duplicates data already present in our native 
   xfrm_userpolicy_info format.

I like this solution, it seems the cleanest.

Could someone implement this fix and send me the patch?
I'm very backlogged for the next day or so...
Permalink | Reply | 2 comments |
headers
James Morris | 3 Mar 2003 13:13
Picon

[PATCH] Re: IPSec: setkey -DP freezes machine

On Mon, 3 Mar 2003, David S. Miller wrote:

>    Alternatively, a family parameter could be added to the compile_policy() 
>    operation, but this duplicates data already present in our native 
>    xfrm_userpolicy_info format.
> 
> I like this solution, it seems the cleanest.
> 

Ok, here's a patch which does this.

I've also added check to verify_newpolicy_info() so that we don't run into
the same problem for policies provided via the netlink interface.

Tom, would you let me know if this works for you, as my racoon isn't
working yet.

- James
--

-- 
James Morris
<jmorris <at> intercode.com.au>

diff -urN -X dontdiff linux-2.5.63.orig/include/net/xfrm.h linux-2.5.63.w1/include/net/xfrm.h
--- linux-2.5.63.orig/include/net/xfrm.h	Fri Feb 21 00:44:01 2003
+++ linux-2.5.63.w1/include/net/xfrm.h	Mon Mar  3 22:19:40 2003
 <at>  <at>  -223,7 +223,7  <at>  <at> 
 	char			*id;
 	int			(*notify)(struct xfrm_state *x, int event);
 	int			(*acquire)(struct xfrm_state *x, struct xfrm_tmpl *, struct xfrm_policy *xp, int dir);
-	struct xfrm_policy	*(*compile_policy)(int opt, u8 *data, int len, int *dir);
(Continue reading)

Permalink | Reply | 1 comment |

Gmane