From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24309 invoked by alias); 17 Jun 2005 10:58:00 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 24263 invoked by uid 22791); 17 Jun 2005 10:57:52 -0000 Received: from prix.tandberg.no (HELO prix.tandberg.no) (194.196.35.10) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 17 Jun 2005 10:57:52 +0000 Received: from 47mail.eu.tandberg.int (47mail.eu.tandberg.int [10.0.0.25]) by prix.tandberg.no (8.12.10/8.12.10) with ESMTP id j5HAvo4n005610; Fri, 17 Jun 2005 12:57:50 +0200 Received: from EXMAIL.eu.tandberg.int ([194.196.35.11]) by 47mail.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Jun 2005 12:57:50 +0200 Received: from [10.47.14.177] ([10.47.14.177]) by EXMAIL.eu.tandberg.int with Microsoft SMTPSVC(5.0.2195.6713); Fri, 17 Jun 2005 12:57:49 +0200 Message-ID: <42B2ACAD.5030608@tandberg.net> Date: Fri, 17 Jun 2005 10:58:00 -0000 From: Sturle Mastberg User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 MIME-Version: 1.0 To: Gary Thomas CC: eCos Discussion References: <42B28F30.1070905@tandberg.net> <1119002495.13965.224.camel@hermes> In-Reply-To: <1119002495.13965.224.camel@hermes> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ECOS] Possible fix for duplicated ARP entries in the FreeBSD stack X-SW-Source: 2005-06/txt/msg00135.txt.bz2 Gary Thomas wrote: > On Fri, 2005-06-17 at 10:52 +0200, Sturle Mastberg wrote: > >>Hello, >> >>For some time I've had problem with duplicated ARP entries that have >>caused all sorts of problems. I searched the archive and discovered that >>the problem had been reported before: >> >> >>http://sourceware.org/ml/ecos-discuss/2004-11/msg00097.html >> >> >>My proposal to a fix is to make the sockaddr_inarp struct >>(include/netinet/if_ether.h) equal in size to the sockaddr struct by >>padding it at the end. This is exactly what is done to the sockaddr_in >>struct (include/netinet/in.h) for different reasons. >> >> >>I reached this conclusion after I discovered that two virutally >>identical calls to rtalloc1 (net/route.c) returned different results. >>The first instance appears in arplookup (netinet/if_ether.c) where the >>first parameter to rtalloc1 is a struct sockaddr_inarp cast to a struct >>sockaddr. The second instance appears in ip_output (netinet/ip_output) >>via rtalloc_ign (net/route.c) where the first parameter to rtalloc1 is >>an actual struct sockaddr. The rtalloc1 function does a radix tree >>search with a call to the rn_match function (net/radix.c). A closer look >>at this code reveals that it does indeed depend on the size of the >>supplied struct. >> >> >>The only conclusion a can draw from this is that the three structs: >>sockaddr, sockaddr_in and sockaddr_inarp must all be of equal size. I >>have checked the FreeBSD source repository that this is the case for the >>original code. >> >> >>While browsing the FreeBSD source repository I discovered that the >>sa_data character array member of the sockaddr struct was increased in >>size in the eCos FreeBSD stack. Does anyone know why this increase was >>introduced in eCos? > > > Can you provide the details of what you found? i.e. exactly how > these structures were modified during the port? [more likely, you're > looking at a newer version of the FreeBSD code than I used and the > changes happened in the BSD codebase] In any case, then we can analyze > how things are different and what might need to be done. > > Thanks > The sockaddr struct in socket.h v1.39.2.7 in FreeBSD (which is the version the eCos port is based on) looks like this: struct sockaddr { u_char sa_len; /* total length */ sa_family_t sa_family; /* address family */ char sa_data[14]; /* actually longer; address value */ }; This structure has remained unchanged in FreeBSD from first to current version. I suspect the somehwat curious size of sa_data is due to the fact that the size of this struct must match that of the sockaddr_inarp struct. Here is the whole revision history: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/socket.h The first version of socket.h in the eCos source repository looks like this: struct sockaddr { u_char sa_len; /* total length */ sa_family_t sa_family; /* address family */ char sa_data[30]; /* actually longer; address value */ }; The sa_data member has increased 16 bytes in size for no apparent reason and hench the reason for my question. This size increase will also likely lead to a performance degradation, since the radix tree search algorithm does a byte by byte comparison for an exact match whenever an ARP cache entry is looked up (which is for every packet that is sent). This comparison, as mentioned earlier, depends on the size of the supplied struct (sockaddr[_in[arp]]) and now it has to deal with a struct that is twice the size is once was. Regards, SM -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss