From owner-netdev@oss.sgi.com Fri Dec  1 01:02:47 2000
Received:  by oss.sgi.com id <S553959AbQLAJC2>;
	Fri, 1 Dec 2000 01:02:28 -0800
Received: from se1.cogenit.fr ([195.68.53.173]:15890 "EHLO se1.cogenit.fr")
	by oss.sgi.com with ESMTP id <S553956AbQLAJCL>;
	Fri, 1 Dec 2000 01:02:11 -0800
Received: (from romieu@localhost)
	by se1.cogenit.fr (8.11.1/8.11.1) id eB191Ob05178;
	Fri, 1 Dec 2000 10:01:24 +0100
Date:   Fri, 1 Dec 2000 10:01:24 +0100
From:   Francois romieu <romieu@cogenit.fr>
To:     Ivan Passos <lists@cyclades.com>
Cc:     linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
Message-ID: <20001201100124.A4986@se1.cogenit.fr>
Reply-To: romieu@ensta.fr
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <Pine.LNX.4.10.10011301103320.4692-100000@main.cyclades.com>; from lists@cyclades.com on Thu, Nov 30, 2000 at 11:16:52AM -0800
X-Organisation: Marie's fan club - I
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

[netdev Cced]

The Thu, Nov 30, 2000 at 11:16:52AM -0800, Ivan Passos wrote :
[...]
> For synchronous network interfaces, besides configuring network parameters
> such as IP address, netmask, MTU, etc., the system should also configure
> parameters specific to these sync i/f's, such as media (e.g V.35, X.21,
> T1, E1), clock (internal or external, and value if int.), protocol (e.g
> PPP, HDLC, Frame Relay), etc.
> What I noticed was that each synchronous board in Linux provides a
> different way of doing this, and it would be good for users to have a
> single, standard interface (such as ifconfig) to do this type of
> configuration. Maybe even patch ifconfig itself, I don't know ...
> 
> Questions:
> - Is there any existing _standard_ interface to do that??

No.

> - If not, is there any existing _standard_ infrastructure (e.g. ioctls and
>   structures) so that I can write an application to do that over this 
>   standard structure?

x25 does things like this:
#define SIOCX25GSUBSCRIP        (SIOCPROTOPRIVATE + 0)
#define SIOCX25SSUBSCRIP        (SIOCPROTOPRIVATE + 1)
...
Thus one could use private ioctl behind SIOCDEVPRIVATE and SIOCPROTOPRIVATE as
defined in include/linux/sockios.h. Something under /proc(/sys ?) is 
possible too but I would ask for the policy that applies to /proc before
coding.

> - If not, where would be the right place in the kernel to change in order 
>   to implement such infrastructure?

net/* for the protocol handler. 
include/linux/if_arp.h
include/linux/if_ether.h

Some place may be updated too:
net/lapb/*
net/x25/*
net/wanrouter
drivers/char/n_hdlc.c
drivers/net/wan/*

> I'm interested in implementing this, but I don't want to reinvent the
> wheel (if such wheel exists ...).

Ditto.

--
Ueimor

From owner-netdev@oss.sgi.com Fri Dec  1 02:27:28 2000
Received:  by oss.sgi.com id <S553963AbQLAK1S>;
	Fri, 1 Dec 2000 02:27:18 -0800
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:3588 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S553958AbQLAK0x>; Fri, 1 Dec 2000 02:26:53 -0800
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id TAA00597
	for <netdev@oss.sgi.com>; Fri, 1 Dec 2000 19:26:36 +0900
To:     netdev@oss.sgi.com
Subject: udpv6 multicast delivery on linux24 and linux22
X-Mailer: Mew version 1.94 on XEmacs 21.1 (Capitol Reef)
X-URL:  http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20001201192636B.yoshfuji@ecei.tohoku.ac.jp>
Date:   Fri, 01 Dec 2000 19:26:36 +0900
From:   YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= 
        <yoshfuji@ecei.tohoku.ac.jp>
X-Dispatcher: imput version 990905(IM130)
Lines:  28
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Is this fix (for udpv6_mcast_deliver()) correct?

I guess you're confusing similar code in ipv4/udp.c;
order of arguments for udp_XX_mcast_next() is different between
ipv6 and ipv4.

Index: udp.c
===================================================================
RCS file: /cvsroot/usagi/kernel/linux24/net/ipv6/udp.c,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 udp.c
--- linux24/net/ipv6/udp.c	2000/11/01 04:31:45	1.1.1.5
+++ linux24/net/ipv6/udp.c	2000/12/01 10:17:29
@@ -577,8 +577,8 @@
 
 	buff = NULL;
 	sk2 = sk;
-	while((sk2 = udp_v6_mcast_next(sk2->next, uh->dest, saddr,
-						  uh->source, daddr, dif))) {
+	while((sk2 = udp_v6_mcast_next(sk2->next, uh->dest, daddr,
+						  uh->source, saddr, dif))) {
 		if (!buff) {
 			buff = skb_clone(skb, GFP_ATOMIC);
 			if (!buff)

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@linux-ipv6.org>
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Fri Dec  1 02:28:48 2000
Received:  by oss.sgi.com id <S553965AbQLAK2h>;
	Fri, 1 Dec 2000 02:28:37 -0800
Received: from smtp1.cern.ch ([137.138.128.38]:28425 "EHLO smtp1.cern.ch")
	by oss.sgi.com with ESMTP id <S553961AbQLAK2a>;
	Fri, 1 Dec 2000 02:28:30 -0800
Received: from cern.ch (IDENT:futo@pccscn05.cern.ch [137.138.33.55])
	by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id LAA16325;
	Fri, 1 Dec 2000 11:28:23 +0100 (MET)
X-Authentication-Warning: smtp1.cern.ch: Host IDENT:futo@pccscn05.cern.ch [137.138.33.55] claimed to be cern.ch
Message-ID: <3A277D40.514F538E@cern.ch>
Date:   Fri, 01 Dec 2000 11:28:16 +0100
From:   Endre Futo <Endre.Futo@cern.ch>
Organization: CERN
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.17pre11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev@oss.sgi.com
CC:     Stig =?iso-8859-1?Q?Ven=E5s?= <venaas@alfa.itea.ntnu.no>
Subject: IPv6 source address selection
References: <3A277435.FC971E52@cern.ch> <20001201105815.A10882@itea.ntnu.no>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Dear All,

I applied the patch
http://www.venaas.priv.no/ipv6/srcaddrsel.html 
of Stig Venås to kernel 2.4.0-test8, it works well.
I would like to know if his patch will be included in the final
version of kernel 2.4.0.

Here at CERN we set up an experimental network to test IPv6
applications. Our machines have three IPv6 addresses and for
some applications it is essential to choose the right route
through the network, which can be done only if the source
address of the client application match with the destination
address. Therefore I consider the patch of Stig Venås very
useful, it solves the problem and it would be useful to
include it in the final version of kernel 2.4.0. If not
we have to patch the source code for each Linux box on the
exerimental IPv6 network. And perhaps not only here at our
institute.

Regards: Endre Futo

From owner-netdev@oss.sgi.com Fri Dec  1 02:32:48 2000
Received:  by oss.sgi.com id <S553967AbQLAKcj>;
	Fri, 1 Dec 2000 02:32:39 -0800
Received: from a203-167-249-89.reverse.clear.net.nz ([203.167.249.89]:9996
        "HELO metastasis.f00f.org") by oss.sgi.com with SMTP
	id <S553964AbQLAKca>; Fri, 1 Dec 2000 02:32:30 -0800
Received: by metastasis.f00f.org (Postfix, from userid 1000)
	id 5EF9D9DAB; Fri,  1 Dec 2000 23:32:27 +1300 (NZDT)
Date:   Fri, 1 Dec 2000 23:32:27 +1300
From:   Chris Wedgwood <cw@f00f.org>
To:     romieu@ensta.fr
Cc:     Ivan Passos <lists@cyclades.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
Message-ID: <20001201233227.A9457@metastasis.f00f.org>
References: <Pine.LNX.4.10.10011301103320.4692-100000@main.cyclades.com> <20001201100124.A4986@se1.cogenit.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001201100124.A4986@se1.cogenit.fr>; from romieu@cogenit.fr on Fri, Dec 01, 2000 at 10:01:24AM +0100
X-No-Archive: Yes
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, Dec 01, 2000 at 10:01:24AM +0100, Francois romieu wrote:

    > Questions:
    > - Is there any existing _standard_ interface to do that??
    
    No.

[...]

    > I'm interested in implementing this, but I don't want to reinvent the
    > wheel (if such wheel exists ...).
    
    Ditto.


Actually; Ethernet badly needs something like this too. I would kill
to be able to do something like:

	ifconfig eth0 speed 100 duplex full

o across different networks cards -- I've been thinking about it of
late as I had to battle with this earlier this week; depending on
what network card you use, you need different magic incarnations to
do the above.

A standard interface is really needed; unless anyone objects I may
look at drafting something up -- but it will require some input if it
is not to look completely Ethernet centric.



  --cw


From owner-netdev@oss.sgi.com Fri Dec  1 03:01:39 2000
Received:  by oss.sgi.com id <S553969AbQLALB3>;
	Fri, 1 Dec 2000 03:01:29 -0800
Received: from ns.caldera.de ([212.34.180.1]:11793 "EHLO ns.caldera.de")
	by oss.sgi.com with ESMTP id <S553966AbQLALBF>;
	Fri, 1 Dec 2000 03:01:05 -0800
Received: (from hch@localhost)
	by ns.caldera.de (8.9.3/8.9.3) id MAA14789;
	Fri, 1 Dec 2000 12:00:06 +0100
Date:   Fri, 1 Dec 2000 12:00:06 +0100
Message-Id: <200012011100.MAA14789@ns.caldera.de>
From:   Christoph Hellwig <hch@caldera.de>
To:     cw@f00f.org (Chris Wedgwood)
Cc:     Ivan Passos <lists@cyclades.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com, romieu@ensta.fr
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
X-Newsgroups: caldera.lists.linux.kernel
In-Reply-To: <20001201233227.A9457@metastasis.f00f.org>
User-Agent: tin/1.4.1-19991201 ("Polish") (UNIX) (Linux/2.2.14 (i686))
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In article <20001201233227.A9457@metastasis.f00f.org> you wrote:
> Actually; Ethernet badly needs something like this too. I would kill
> to be able to do something like:

> 	ifconfig eth0 speed 100 duplex full

> o across different networks cards -- I've been thinking about it of
> late as I had to battle with this earlier this week; depending on
> what network card you use, you need different magic incarnations to
> do the above.

> A standard interface is really needed; unless anyone objects I may
> look at drafting something up -- but it will require some input if it
> is not to look completely Ethernet centric.

For ethernet we have ethtool, recently changed from sparc only to
architecture independend.

	Christoph

-- 
Always remember that you are unique.  Just like everyone else.

From owner-netdev@oss.sgi.com Fri Dec  1 04:09:09 2000
Received:  by oss.sgi.com id <S553971AbQLAMJA>;
	Fri, 1 Dec 2000 04:09:00 -0800
Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:35602 "EHLO
        www.linux.org.uk") by oss.sgi.com with ESMTP id <S553968AbQLAMIn>;
	Fri, 1 Dec 2000 04:08:43 -0800
Received: from dyn-33.linux.theplanet.co.uk ([195.92.244.33] helo=caramon.arm.linux.org.uk)
	by www.linux.org.uk with esmtp (Exim 3.13 #1)
	id 141ozO-0006dD-00
	for netdev@oss.sgi.com; Fri, 01 Dec 2000 12:08:31 +0000
Received: from flint.arm.linux.org.uk (IDENT:root@flint.arm.linux.org.uk [192.168.0.4])
	by caramon.arm.linux.org.uk (8.11.0/8.11.0) with ESMTP id eB1C79d08774;
	Fri, 1 Dec 2000 12:07:49 GMT
Received: (from rmk@localhost)
	by flint.arm.linux.org.uk (8.11.0/8.11.0) id eB1C78523251;
	Fri, 1 Dec 2000 12:07:08 GMT
From:   Russell King <rmk@arm.linux.org.uk>
Message-Id: <200012011207.eB1C78523251@flint.arm.linux.org.uk>
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
To:     cw@f00f.org (Chris Wedgwood)
Date:   Fri, 1 Dec 2000 12:07:08 +0000 (GMT)
Cc:     romieu@ensta.fr, lists@cyclades.com (Ivan Passos),
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
In-Reply-To: <20001201233227.A9457@metastasis.f00f.org> from "Chris Wedgwood" at Dec 01, 2000 11:32:27 PM
X-Location: london.england.earth.mulky-way.universe
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Chris Wedgwood writes:
> Actually; Ethernet badly needs something like this too. I would kill
> to be able to do something like:
> 
> 	ifconfig eth0 speed 100 duplex full
> 
> o across different networks cards -- I've been thinking about it of
> late as I had to battle with this earlier this week; depending on
> what network card you use, you need different magic incarnations to
> do the above.
> 
> A standard interface is really needed; unless anyone objects I may
> look at drafting something up -- but it will require some input if it
> is not to look completely Ethernet centric.

We already have a standard interface for this, but many drivers do not
support it.  Its called "ifconfig eth0 media xxx":

bash-2.04# ifconfig --help
Usage:
  ifconfig [-a] [-i] [-v] [-s] <interface> [[<AF>] <address>]
...
  [mem_start <NN>]  [io_addr <NN>]  [irq <NN>]  [media <type>]
...
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rmk@arm.linux.org.uk      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

From owner-netdev@oss.sgi.com Fri Dec  1 04:15:59 2000
Received:  by oss.sgi.com id <S553975AbQLAMPk>;
	Fri, 1 Dec 2000 04:15:40 -0800
Received: from se1.cogenit.fr ([195.68.53.173]:2314 "EHLO se1.cogenit.fr")
	by oss.sgi.com with ESMTP id <S553972AbQLAMP0>;
	Fri, 1 Dec 2000 04:15:26 -0800
Received: (from romieu@localhost)
	by se1.cogenit.fr (8.11.1/8.11.1) id eB1CF1108397;
	Fri, 1 Dec 2000 13:15:01 +0100
Date:   Fri, 1 Dec 2000 13:15:01 +0100
From:   Francois Romieu <romieu@cogenit.fr>
To:     Chris Wedgwood <cw@f00f.org>
Cc:     Ivan Passos <lists@cyclades.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
Message-ID: <20001201131501.A8145@se1.cogenit.fr>
Reply-To: romieu@ensta.fr
References: <Pine.LNX.4.10.10011301103320.4692-100000@main.cyclades.com> <20001201100124.A4986@se1.cogenit.fr> <20001201233227.A9457@metastasis.f00f.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <20001201233227.A9457@metastasis.f00f.org>
X-Organisation: Marie's fan club
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Chris Wedgwood <cw@f00f.org> écrit :
[...]
> o across different networks cards -- I've been thinking about it of
> late as I had to battle with this earlier this week; depending on
> what network card you use, you need different magic incarnations to
> do the above.
> 
> A standard interface is really needed; unless anyone objects I may
> look at drafting something up -- but it will require some input if it
> is not to look completely Ethernet centric.

Regarding the clocking issue, synchronous interfaces need to know wether
the signal is externally provided or internally generated. The latter
implies to set the frequency too.

-- 
Ueimor

From owner-netdev@oss.sgi.com Fri Dec  1 04:36:29 2000
Received:  by oss.sgi.com id <S553977AbQLAMgJ>;
	Fri, 1 Dec 2000 04:36:09 -0800
Received: from nas1-12.kmp.club-internet.fr ([213.44.17.12]:45295 "EHLO
        microsoft.com") by oss.sgi.com with ESMTP id <S553974AbQLAMfp>;
	Fri, 1 Dec 2000 04:35:45 -0800
Received: (from xav@localhost)
	by microsoft.com (8.9.3/8.9.3) id NAA04009;
	Fri, 1 Dec 2000 13:30:34 +0100
Message-Id: <200012011230.NAA04009@microsoft.com>
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
From:   Xavier Bestel <xavier.bestel@free.fr>
To:     Christoph Hellwig <hch@caldera.de>
Cc:     cw@f00f.org, Ivan Passos <lists@cyclades.com>,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com, romieu@ensta.fr
In-Reply-To: <200012011100.MAA14789@ns.caldera.de>
Content-Type: text/plain
X-Mailer: Evolution 0.6 (Developer Preview)
Date:   01 Dec 2000 11:30:33 -0100
Mime-Version: 1.0
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

> In article <20001201233227.A9457@metastasis.f00f.org> you wrote:
> > Actually; Ethernet badly needs something like this too. I would kill
> > to be able to do something like:
> 
> >     ifconfig eth0 speed 100 duplex full
> 
> > o across different networks cards -- I've been thinking about it of
> > late as I had to battle with this earlier this week; depending on
> > what network card you use, you need different magic incarnations to
> > do the above.
> 
> > A standard interface is really needed; unless anyone objects I may
> > look at drafting something up -- but it will require some input if it
> > is not to look completely Ethernet centric.
> 
> For ethernet we have ethtool, recently changed from sparc only to
> architecture independend.

It should be consistent with the wireless extentions (same goal)

Xav

From owner-netdev@oss.sgi.com Fri Dec  1 05:01:30 2000
Received:  by oss.sgi.com id <S553979AbQLANBU>;
	Fri, 1 Dec 2000 05:01:20 -0800
Received: from se1.cogenit.fr ([195.68.53.173]:6925 "EHLO se1.cogenit.fr")
	by oss.sgi.com with ESMTP id <S553976AbQLANA7>;
	Fri, 1 Dec 2000 05:00:59 -0800
Received: (from romieu@localhost)
	by se1.cogenit.fr (8.11.1/8.11.1) id eB1D0g209386;
	Fri, 1 Dec 2000 14:00:42 +0100
Date:   Fri, 1 Dec 2000 14:00:42 +0100
From:   Francois Romieu <romieu@cogenit.fr>
To:     Russell King <rmk@arm.linux.org.uk>
Cc:     Chris Wedgwood <cw@f00f.org>, Ivan Passos <lists@cyclades.com>,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
Message-ID: <20001201140042.A8572@se1.cogenit.fr>
References: <20001201233227.A9457@metastasis.f00f.org> <200012011207.eB1C78523251@flint.arm.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <200012011207.eB1C78523251@flint.arm.linux.org.uk>
X-Organisation: Marie's fan club
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Russell King <rmk@arm.linux.org.uk> écrit :
[...]
> We already have a standard interface for this, but many drivers do not
> support it.  Its called "ifconfig eth0 media xxx":
> 
> bash-2.04# ifconfig --help
> Usage:
>   ifconfig [-a] [-i] [-v] [-s] <interface> [[<AF>] <address>]
> ...
>   [mem_start <NN>]  [io_addr <NN>]  [irq <NN>]  [media <type>]

Ok. Hmmm... If I want to do something like 
'ifconfig scc0 media some_frequency up' as I hope to set scc0 as a DCE (or 
ifconfig scc0 media auto up' for a DTE), I must teach ifconfig.c to 
distinguish Ethernet and synchrone interface based on interface.type, right ? 

-- 
Ueimor

From owner-netdev@oss.sgi.com Fri Dec  1 05:14:30 2000
Received:  by oss.sgi.com id <S553981AbQLANOU>;
	Fri, 1 Dec 2000 05:14:20 -0800
Received: from mail.iwr.uni-heidelberg.de ([129.206.104.30]:34807 "EHLO
        mail.iwr.uni-heidelberg.de") by oss.sgi.com with ESMTP
	id <S553978AbQLANOE>; Fri, 1 Dec 2000 05:14:04 -0800
Received: from kenzo.iwr.uni-heidelberg.de (IDENT:root@kenzo.iwr.uni-heidelberg.de [129.206.120.29])
	by mail.iwr.uni-heidelberg.de (8.11.1/8.11.1) with ESMTP id eB1DE1b19584;
	Fri, 1 Dec 2000 14:14:01 +0100 (MET)
Received: from localhost (bogdan@localhost)
	by kenzo.iwr.uni-heidelberg.de (8.9.3/8.9.3) with ESMTP id OAA08185;
	Fri, 1 Dec 2000 14:14:00 +0100
Date:   Fri, 1 Dec 2000 14:14:00 +0100 (CET)
From:   Bogdan Costescu <Bogdan.Costescu@IWR.Uni-Heidelberg.De>
To:     Chris Wedgwood <cw@f00f.org>
cc:     <romieu@ensta.fr>, Ivan Passos <lists@cyclades.com>,
        <linux-kernel@vger.kernel.org>, <netdev@oss.sgi.com>
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
In-Reply-To: <20001201233227.A9457@metastasis.f00f.org>
Message-ID: <Pine.LNX.4.30.0012011359270.7367-100000@kenzo.iwr.uni-heidelberg.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, 1 Dec 2000, Chris Wedgwood wrote:

> Actually; Ethernet badly needs something like this too. I would kill
> to be able to do something like:
>
> 	ifconfig eth0 speed 100 duplex full

Even if you are thinking about Ethernet only, it's not easy to do it. Most
modern NICs have MII transceivers, where media setting is more or less
following a standard. All drivers written by Donald Becker and probably
everything derived from them support MII get/set operations from
user-space through ioctls, using mii-diag (from ftp.scyld.com).
But there are NICs which do not have MII transceivers and media
setting/selection is NIC-specific. Take a look at the media specific
module options for several drivers (e.g. 3c59x and tulip) and you'll see
what I'm talking about.

Moreover, with the proposed ifconfig interface, there is a problem: do you
want the media setting to be locked ? Quite a lot of NICs can do
NWAY autonegotiation or the driver can go through the available modes
trying to get one working. So if you say "I want to use this speed", do
you want to specifically use that speed or give it just as a starting
point for the driver which can decrease the speed in case it's not able to
get it ? (the example is Ethernet specific, but the ideea is not).

And finally (also Ethernet specific): some devices don't like forced
media settings when they support autonegotiation. Look at the tulip recent
archives for examples.

Sincerely,

Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De



From owner-netdev@oss.sgi.com Fri Dec  1 05:46:50 2000
Received:  by oss.sgi.com id <S553983AbQLANqk>;
	Fri, 1 Dec 2000 05:46:40 -0800
Received: from salisbury.labs.futuretv.com ([194.216.164.17]:22522 "EHLO
        mail.futuretv.com") by oss.sgi.com with ESMTP id <S553980AbQLANqO>;
	Fri, 1 Dec 2000 05:46:14 -0800
Received: from pig.labs.futuretv.com ([192.168.33.33])
	by mail.futuretv.com with esmtp (Exim 3.12 #1)
	id 141qUA-0005ze-00; Fri, 01 Dec 2000 13:44:22 +0000
Received: from localhost
	([::ffff:127.0.0.1] helo=pig.labs.futuretv.com ident=pb)
	by pig.labs.futuretv.com with esmtp (Exim 3.12 #1)
	id 141qU9-0005Xr-00; Fri, 01 Dec 2000 13:44:21 +0000
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To:     Russell King <rmk@arm.linux.org.uk>
cc:     cw@f00f.org (Chris Wedgwood), romieu@ensta.fr,
        lists@cyclades.com (Ivan Passos), linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux 
In-reply-to: Your message of "Fri, 01 Dec 2000 12:07:08 GMT."
             <200012011207.eB1C78523251@flint.arm.linux.org.uk> 
From:   Philip Blundell <pb@futuretv.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Fri, 01 Dec 2000 13:44:21 +0000
Message-Id: <E141qU9-0005Xr-00@pig.labs.futuretv.com>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In message <200012011207.eB1C78523251@flint.arm.linux.org.uk>, Russell King wri
tes:
>We already have a standard interface for this, but many drivers do not
>support it.  Its called "ifconfig eth0 media xxx":

The Ethtool interface is rather better.

p.



From owner-netdev@oss.sgi.com Fri Dec  1 09:44:30 2000
Received:  by oss.sgi.com id <S553987AbQLARoL>;
	Fri, 1 Dec 2000 09:44:11 -0800
Received: from relay2.smtp.psi.ca ([154.11.137.2]:24248 "EHLO
        relay2.smtp.psi.ca") by oss.sgi.com with ESMTP id <S553984AbQLARnl>;
	Fri, 1 Dec 2000 09:43:41 -0800
Received: from [205.250.170.202] (helo=netvipswitch.netcorp.qc.ca)
	by relay2.smtp.psi.ca with esmtp (Exim 1.90 #1)
	id 141uDS-0000Lo-00; Fri, 1 Dec 2000 12:43:22 -0500
From:   Francois Desloges <fd@vipswitch.com>
To:     romieu@ensta.fr, Francois romieu <romieu@cogenit.fr>,
        Ivan Passos <lists@cyclades.com>
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
Date:   Fri, 1 Dec 2000 11:26:59 -0500
Content-Type: text/plain
Cc:     linux-kernel@vger.kernel.org, netdev@oss.sgi.com
References: <20001201100124.A4986@se1.cogenit.fr>
In-Reply-To: <20001201100124.A4986@se1.cogenit.fr>
MIME-Version: 1.0
Message-Id: <00120112303800.07574@dual.vip.ca>
Content-Transfer-Encoding: 8bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, 01 Dec 2000, Francois romieu wrote:
> [netdev Cced]
> 
> The Thu, Nov 30, 2000 at 11:16:52AM -0800, Ivan Passos wrote :
> [...]
> > For synchronous network interfaces, besides configuring network parameters
> > such as IP address, netmask, MTU, etc., the system should also configure
> > parameters specific to these sync i/f's, such as media (e.g V.35, X.21,
> > T1, E1), clock (internal or external, and value if int.), protocol (e.g
> > PPP, HDLC, Frame Relay), etc.
> > What I noticed was that each synchronous board in Linux provides a
> > different way of doing this, and it would be good for users to have a
> > single, standard interface (such as ifconfig) to do this type of
> > configuration. Maybe even patch ifconfig itself, I don't know ...
> > 
> > Questions:
> > - Is there any existing _standard_ interface to do that??
> 
> No.
> 

Humm...  If I recall the thread about 802.1Q that happened in June on netdev,
(See the thread starting at
http://sloth.wcug.wwu.edu/lists/netdev/200006/msg00003.html ), and I add up
with what I read here, I think we would be due for a major rewrite of the Layer
2 akin to what Alexey did for Layer 3 in 2.2.

A lot of questions need to be answered like:

What is _really_ a net_device ? (Hardware card, interface to tag a L3 address
on, etc..)

Considering the following divisions that exist today:
 - A hardware card (or let's say a chipset so that anything on a mobo count as
   well) can have many physical ports. I will call them PHY.
 - A PHY can use TDM or Wavelenght Multiplexing (including Lambdas on
   GEthernet and 10 GEthernet fibers) or both ! to create physical channels.
   I'll call them Channels.
 - Each of these Channels may further on use logics in header to (possibly)
   create virtual links (802.1Q, MPLS (?)) Let's call this top abstraction a
   Link, that is, something that can receive a L3 address.

Consider as well that you want to maintain the actual funtionnality of the
kernel, including:
 - Bridging.
 - 802.1Q VLANing (with a patch from one of Gleb or Ben's Project)
 - Bridging/802.1Q (Is this possible yet ?) 
 - Hooking a _lot_ of different L3 on top of L2 (including AplleTalk, etc)
 - simple user tools like, ifconfig, and very powerful one, like ip.

How many abstractions are really desirable at Layer 2 in order to limit the
proliferation of tools linked to specific hardware?

-- 
François Desloges
fd@vipswitch.com

From owner-netdev@oss.sgi.com Fri Dec  1 11:06:21 2000
Received:  by oss.sgi.com id <S553999AbQLATGC>;
	Fri, 1 Dec 2000 11:06:02 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:44046 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553799AbQLATFe>;
	Fri, 1 Dec 2000 11:05:34 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA14357; Fri, 1 Dec 2000 22:05:11 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012011905.WAA14357@ms2.inr.ac.ru>
Subject: Re: linux to solaris tcp issues on WAN
To:     pp@netppl.FI (Pekka Pietikainen)
Date:   Fri, 1 Dec 2000 22:05:11 +0300 (MSK)
Cc:     netdev@oss.sgi.com
In-Reply-To: <20001127123108.A7599@netppl.fi> from "Pekka Pietikainen" at Nov 27, 0 01:45:07 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 996       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> > I have tested this with Linux 2.2.12, 2.2.14, 2.2.16, 2.2.17 and
> > 2.4.0-test6 kernels on the sender, and Solaris 2.6 and 2.7 for the 
> > receiver, and the results are the same.   
....
> > From: Vern Paxson <vern@ee.lbl.gov>
...
> > Well, the problem is that the sender is miscomputing its RTO, setting it to
> > a value that's much too low (according to the standard).

I hope Paxson interpreted the problem incorrectly. 8)
(following his own researchs, which are not quite right and do not
apply to linux at all)

I think real reason is that Linux had bug estimating rtt using as sample
the last acked segment, so that delack bias was not taken into account
at all.

Could you check this with 2.2?

In fact the fix is very simple: in tcp_clean_rtx_queue() use __s32
for seq_rtt, intialize it to something negative and update only
when it is negative, so that only the first segemnt is used for sampling.
Can you make it yourself? (I do not have any 2.2 tree right now.)

Alexey

From owner-netdev@oss.sgi.com Fri Dec  1 12:49:11 2000
Received:  by oss.sgi.com id <S554007AbQLAUtB>;
	Fri, 1 Dec 2000 12:49:01 -0800
Received: from relay1.smtp.psi.ca ([154.11.136.226]:64134 "EHLO
        relay1.smtp.psi.ca") by oss.sgi.com with ESMTP id <S554004AbQLAUsl>;
	Fri, 1 Dec 2000 12:48:41 -0800
Received: from [205.250.170.202] (helo=netvipswitch.netcorp.qc.ca)
	by relay1.smtp.psi.ca with esmtp (Exim 3.13 #3)
	id 141x6m-0005QU-00
	for netdev@oss.sgi.com; Fri, 01 Dec 2000 15:48:40 -0500
From:   Francois Desloges <fd@vipswitch.com>
To:     netdev@oss.sgi.com
Subject: Re: CLOCK_SOURCE for shaper
Date:   Fri, 1 Dec 2000 12:13:12 -0500
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <00120115355704.07574@dual.vip.ca>
Content-Transfer-Encoding: 8bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Well in relation with that L2 abstractions discussion...

With the great improvement of softnet in 2.4, the drivers are responsible to get
scheduled, which is done more efficently by real hardware that generates
interrupts, than virtual shaping abstractions.(I don't know for other
pseudo devices such as tunnels, 802.1Q net_device, etc ?)

At least with the qdisc shapers platforms other than Intel (we use ARM) are
limited to get scheduled when new traffic arrives or at HZ frequency.
This gives _bad_ shaping resolution. Somebody here hacked another timer system
just for net/sched so that we don't have to play with HZ, which have more to do
with processes than softnet, IMHO (Am I wrong ?). So this guy created that
second timer system based on an interrupt that awake at a frequency of 10kHz.

We chose 10000Hz since at 100 Mbps (FastEth is a pretty standard/good interface
speed) datagrams with MTU of 1500 (*8bits/Byte = 12000 bits) would require
transmission at 8333 Hz. So we do better than MTU provisionning, and at
100Mbps, 10KHz, 1250 bytes (10kb) of smaller packet accumulates, which seem
an affordable burst size. And hey! this gives us a potential floor latency of
0.1 ms, which is much way greater than the earlier 10 ms at HZ a of 100. 

Moreover on system with clockrate > 100MHz this gives > 10000 cycles for job to
get done between potential interruption, which seems ok.

Am I the only one thinking that softnet shaper scheduling share few in common
with regular (more user space oriented) timers ?

Is it a good idea to separate PSCHED_CLOCK_SOURCE from HZ on most platform and
how could it be implemented generally (instead of just for our particular
SA+21285) ?

Thanks
-- 
François Desloges
fd@vipswitch.com

From owner-netdev@oss.sgi.com Sat Dec  2 06:36:21 2000
Received:  by oss.sgi.com id <S554070AbQLBOgL>;
	Sat, 2 Dec 2000 06:36:11 -0800
Received: from laurin.munich.netsurf.de ([194.64.166.1]:4505 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S554066AbQLBOf4>; Sat, 2 Dec 2000 06:35:56 -0800
Received: from fred.muc.de (noidentity@ns1197.munich.netsurf.de [195.180.235.197])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id PAA27194;
	Sat, 2 Dec 2000 15:35:41 +0100 (MET)
Received: by fred.muc.de (Postfix, from userid 500)
	id 271A4E3914; Sat,  2 Dec 2000 15:39:44 +0100 (CET)
Date:   Sat, 2 Dec 2000 15:39:44 +0100
From:   Andi Kleen <ak@muc.de>
To:     kuznet@ms2.inr.ac.ru
Cc:     Pekka Pietikainen <pp@netppl.FI>, netdev@oss.sgi.com
Subject: Re: linux to solaris tcp issues on WAN
Message-ID: <20001202153944.A570@fred.local>
References: <20001127123108.A7599@netppl.fi> <200012011905.WAA14357@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200012011905.WAA14357@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Fri, Dec 01, 2000 at 08:07:06PM +0100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, Dec 01, 2000 at 08:07:06PM +0100, A.N.Kuznetsov wrote:
> Could you check this with 2.2?
> 
> In fact the fix is very simple: in tcp_clean_rtx_queue() use __s32
> for seq_rtt, intialize it to something negative and update only
> when it is negative, so that only the first segemnt is used for sampling.
> Can you make it yourself? (I do not have any 2.2 tree right now.)

Although that is surely right I doubt it'll fix that problem -- the trace
uses timestamps and the seq_rtt from clean_rtx_queue is not used when
a timestamp is available.


-Andi

From owner-netdev@oss.sgi.com Sat Dec  2 08:07:12 2000
Received:  by oss.sgi.com id <S554073AbQLBQHC>;
	Sat, 2 Dec 2000 08:07:02 -0800
Received: from adsl-151-196-236-79.baltmd.adsl.bellatlantic.net ([151.196.236.79]:45652 convert rfc822-to-8bit
        "EHLO vaio.greennet") by oss.sgi.com with ESMTP id <S554069AbQLBQGs>;
	Sat, 2 Dec 2000 08:06:48 -0800
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id LAA17060;
	Sat, 2 Dec 2000 11:09:36 -0500
Date:   Sat, 2 Dec 2000 11:09:35 -0500 (EST)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     Francois Romieu <romieu@cogenit.fr>
cc:     Russell King <rmk@arm.linux.org.uk>, Chris Wedgwood <cw@f00f.org>,
        Ivan Passos <lists@cyclades.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
In-Reply-To: <20001201140042.A8572@se1.cogenit.fr>
Message-ID: <Pine.LNX.4.10.10012021041460.16980-100000@vaio.greennet>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8BIT
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, 1 Dec 2000, Francois Romieu wrote:

> Russell King <rmk@arm.linux.org.uk> écrit :
> [...]
> > We already have a standard interface for this, but many drivers do not
> > support it.  Its called "ifconfig eth0 media xxx":

Uhmmm, it's not a standard if "many drivers do not support it".

It is very easy to hack up code to handle one or two drivers.
But you shouldn't claim the problem is fixed until the approach is tested
with all of the driver.

Hey, I'll make it easy.  Find an approach that fully handles only the Tulip
and 3c59x drivers, and that is consistent.

I'll start you out: the possible 100baseTx configurations for the 3c59x
driver are SYM transceiver, MII transceiver, and "NWay" transceiver.  The
latter two may use autonegotiation, only speed autosensing, or a fixed
speed.  The SYM transceiver version can do static speed sensing.

[[ Note static speed sensing on the 3c595 is potentially evil.  The chip
must generate 100baseTx link beat while checking for 100baseTx link beat.
This commonly hoses a 10baseT repeater with constant collisions.  So does
"auto speed" mean "check for 100baseTx link beat, even though I sense
10baseT" or "do the safe thing and stick with 10baseT". ]]

> Ok. Hmmm... If I want to do something like 
> 'ifconfig scc0 media some_frequency up' as I hope to set scc0 as a DCE (or 
> ifconfig scc0 media auto up' for a DTE), I must teach ifconfig.c to 
> distinguish Ethernet and synchrone interface based on interface.type,
> right ?

Correct.  And just speed isn't good enough for Ethernet.  We have 1/10HPNA,
100base-Fx,Tx,T4.

We should not just give up.
My point is that the issue isn't a trivial one.
Media selection code is the most time consuming and error prone code in many
drivers.  I would have avoiding doing that work if there had been an easy
answer.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993


From owner-netdev@oss.sgi.com Sat Dec  2 08:40:32 2000
Received:  by oss.sgi.com id <S554082AbQLBQkM>;
	Sat, 2 Dec 2000 08:40:12 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:57872 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553691AbQLBQjx>;
	Sat, 2 Dec 2000 08:39:53 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA32529; Sat, 2 Dec 2000 19:39:22 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012021639.TAA32529@ms2.inr.ac.ru>
Subject: Re: linux to solaris tcp issues on WAN
To:     ak@muc.de (Andi Kleen)
Date:   Sat, 2 Dec 2000 19:39:22 +0300 (MSK)
Cc:     pp@netppl.FI, netdev@oss.sgi.com
In-Reply-To: <20001202153944.A570@fred.local> from "Andi Kleen" at Dec 2, 0 03:39:44 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 281       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Although that is surely right I doubt it'll fix that problem -- the trace
> uses timestamps

I had no time to look at dumps yesterday (and I still did not).

Funny, it was the only change to tcp logic.
OK, this is even better. The problem did not disappear then.

Alexey

From owner-netdev@oss.sgi.com Sat Dec  2 11:00:32 2000
Received:  by oss.sgi.com id <S553813AbQLBTAX>;
	Sat, 2 Dec 2000 11:00:23 -0800
Received: from a203-167-249-89.reverse.clear.net.nz ([203.167.249.89]:12292
        "HELO metastasis.f00f.org") by oss.sgi.com with SMTP
	id <S553800AbQLBTAC>; Sat, 2 Dec 2000 11:00:02 -0800
Received: by metastasis.f00f.org (Postfix, from userid 1000)
	id 1641A9DAA; Sun,  3 Dec 2000 07:59:58 +1300 (NZDT)
Date:   Sun, 3 Dec 2000 07:59:58 +1300
From:   Chris Wedgwood <cw@f00f.org>
To:     Donald Becker <becker@scyld.com>
Cc:     Francois Romieu <romieu@cogenit.fr>,
        Russell King <rmk@arm.linux.org.uk>,
        Ivan Passos <lists@cyclades.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
Message-ID: <20001203075958.A1121@metastasis.f00f.org>
References: <20001201140042.A8572@se1.cogenit.fr> <Pine.LNX.4.10.10012021041460.16980-100000@vaio.greennet>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.10.10012021041460.16980-100000@vaio.greennet>; from becker@scyld.com on Sat, Dec 02, 2000 at 11:09:35AM -0500
X-No-Archive: Yes
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sat, Dec 02, 2000 at 11:09:35AM -0500, Donald Becker wrote:

    On Fri, 1 Dec 2000, Francois Romieu wrote:
    
    > Russell King <rmk@arm.linux.org.uk> écrit :
    > [...]
    > > We already have a standard interface for this, but many drivers do not
    > > support it.  Its called "ifconfig eth0 media xxx":
    
    Uhmmm, it's not a standard if "many drivers do not support it".
    
    It is very easy to hack up code to handle one or two drivers.
    But you shouldn't claim the problem is fixed until the approach is tested
    with all of the driver.
    
    Hey, I'll make it easy.  Find an approach that fully handles only the Tulip
    and 3c59x drivers, and that is consistent.

Actually, I starteed work on adding this to the 3c59x code last
night; I am now a little dispondent though as it wasn't as simple as
I first thought it might be.

I am now wondering whether it make sense to break 3c59x into smaller
peices which hander fewer cards each; there soom to be many things
the driver knows about which probably don't relate to my needs.



 --cw

From owner-netdev@oss.sgi.com Sat Dec  2 11:08:23 2000
Received:  by oss.sgi.com id <S554010AbQLBTIN>;
	Sat, 2 Dec 2000 11:08:13 -0800
Received: from mandrakesoft.mandrakesoft.com ([216.71.84.35]:45688 "EHLO convert rfc822-to-8bit
        mandrakesoft.mandrakesoft.com") by oss.sgi.com with ESMTP
	id <S553809AbQLBTIA>; Sat, 2 Dec 2000 11:08:00 -0800
Received: from localhost (jgarzik@localhost)
	by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with SMTP id NAA06976;
	Sat, 2 Dec 2000 13:07:29 -0600
Date:   Sat, 2 Dec 2000 13:07:29 -0600 (CST)
From:   Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com>
To:     Chris Wedgwood <cw@f00f.org>
cc:     Donald Becker <becker@scyld.com>,
        Francois Romieu <romieu@cogenit.fr>,
        Russell King <rmk@arm.linux.org.uk>,
        Ivan Passos <lists@cyclades.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
In-Reply-To: <20001203075958.A1121@metastasis.f00f.org>
Message-ID: <Pine.LNX.3.96.1001202130202.1450B-100000@mandrakesoft.mandrakesoft.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sun, 3 Dec 2000, Chris Wedgwood wrote:
>     > Russell King <rmk@arm.linux.org.uk> écrit :
>     > [...]
>     > > We already have a standard interface for this, but many drivers do not
>     > > support it.  Its called "ifconfig eth0 media xxx":

> Actually, I starteed work on adding this to the 3c59x code last
> night; I am now a little dispondent though as it wasn't as simple as
> I first thought it might be.

Does 'ifconfig eth0 media xxx' wind up calling dev->set_config?

If yes, my guess is correct, I think the proper solution is to:
* create a generic set_config, which does nothing but convert the calls'
semantics into ethtool semantics, and
* add ethtool support to the specific driver

And you might even go so far as to create a generic MII implementation
of ethtool support, so that existing drivers can simply plug in their
mdio_{read,write} functions to automatically get full ethtool support.
(disclaimer:  this is a spur-of-the-moment thought, creating a generic
MII module for ethtool support may not be feasible)

drivers/net/sis900.c implements set_config, if you want an example..

Finally, if you want to just use ethtool directly, grab the SRPM and
install it on your system.

	Jeff




From owner-netdev@oss.sgi.com Sat Dec  2 11:45:33 2000
Received:  by oss.sgi.com id <S554012AbQLBTpX>;
	Sat, 2 Dec 2000 11:45:23 -0800
Received: from adsl-151-196-234-4.baltmd.adsl.bellatlantic.net ([151.196.234.4]:62299
        "EHLO vaio.greennet") by oss.sgi.com with ESMTP id <S554005AbQLBTpH>;
	Sat, 2 Dec 2000 11:45:07 -0800
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id OAA18496;
	Sat, 2 Dec 2000 14:48:10 -0500
Date:   Sat, 2 Dec 2000 14:48:10 -0500 (EST)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     Chris Wedgwood <cw@f00f.org>
cc:     Francois Romieu <romieu@cogenit.fr>,
        Russell King <rmk@arm.linux.org.uk>,
        Ivan Passos <lists@cyclades.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
In-Reply-To: <20001203075958.A1121@metastasis.f00f.org>
Message-ID: <Pine.LNX.4.10.10012021412560.16980-100000@vaio.greennet>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sun, 3 Dec 2000, Chris Wedgwood wrote:

> On Sat, Dec 02, 2000 at 11:09:35AM -0500, Donald Becker wrote:
> 
>     Hey, I'll make it easy.  Find an approach that fully handles only the Tulip
>     and 3c59x drivers, and that is consistent.
> 
> Actually, I starteed work on adding this to the 3c59x code last
> night; I am now a little dispondent though as it wasn't as simple as
> I first thought it might be.
> 
> I am now wondering whether it make sense to break 3c59x into smaller
> peices which hander fewer cards each; there soom to be many things
> the driver knows about which probably don't relate to my needs.

It's certainly possible to break the driver up, but it will be even more of
a problem to maintain.  Some of the complicated media selection code applies
to several generations.  Splitting the driver to have a copy for each
generation means a lot of duplicated code, which quickly leads to version
skew.

The story usually goes like this:

Someone wants to experiment with a driver.  It's always exciting to tweak
the code for the latest and greatest.  But the driver has all of this
complicated stuff for other, usually older, card/kernel versions.  So the
hacker tosses out the code, "simplifying" the driver.  They then release the
"new and improved driver".

They have no CVS tree to maintain, no old driver or hardware versions to
keep track of.  No one has been using the driver for years, and thus there
is no one screaming when their production machine stop working.  All of the
people with problems are just referred to the guy who did the original
driver, who is still expected to be there when things break.  They don't
realize they have just removed all of the excitement and motivation for they
guy who is doing all of the time consuming maintenance and testing work.

I don't mean to pick on 3Com, but the driver they released is a good
example.  It supported only a tiny set of card types that 3Com was currently
selling, and only with the current kernel.  It didn't support the previous
card types, the OEMed versions, or the older kernels.  The assumption was
that my driver would exist to support those hard cases, but by handling the
easy 90% that 3Com would get most of the credit.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993


From owner-netdev@oss.sgi.com Sat Dec  2 12:05:22 2000
Received:  by oss.sgi.com id <S554014AbQLBUFD>;
	Sat, 2 Dec 2000 12:05:03 -0800
Received: from tazenda.demon.co.uk ([158.152.220.239]:11026 "EHLO
        tazenda.demon.co.uk") by oss.sgi.com with ESMTP id <S554011AbQLBUEg>;
	Sat, 2 Dec 2000 12:04:36 -0800
Received: from kings-cross.london.uk.eu.org [::ffff:192.168.2.83] 
	by tazenda.demon.co.uk with esmtp (Exim 3.11 #1 (Debian))
	id 142IrV-0006PC-00; Sat, 02 Dec 2000 20:02:21 +0000
Received: from localhost
	([::ffff:127.0.0.1] helo=tazenda.demon.co.uk ident=pb)
	by kings-cross.london.uk.eu.org with esmtp (Exim 3.12 #1 (Debian))
	id 142IrA-0007hG-00; Sat, 02 Dec 2000 20:02:00 +0000
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To:     Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com>
cc:     Chris Wedgwood <cw@f00f.org>, Donald Becker <becker@scyld.com>,
        Francois Romieu <romieu@cogenit.fr>,
        Russell King <rmk@arm.linux.org.uk>,
        Ivan Passos <lists@cyclades.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux 
In-Reply-To: Message from Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com> 
   of "Sat, 02 Dec 2000 13:07:29 CST." <Pine.LNX.3.96.1001202130202.1450B-100000@mandrakesoft.mandrakesoft.com> 
References: <Pine.LNX.3.96.1001202130202.1450B-100000@mandrakesoft.mandrakesoft.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Sat, 02 Dec 2000 20:02:00 +0000
From:   Philip Blundell <philb@gnu.org>
Message-Id: <E142IrA-0007hG-00@kings-cross.london.uk.eu.org>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>Does 'ifconfig eth0 media xxx' wind up calling dev->set_config?

Yes.

p.



From owner-netdev@oss.sgi.com Sat Dec  2 16:21:34 2000
Received:  by oss.sgi.com id <S553823AbQLCAVO>;
	Sat, 2 Dec 2000 16:21:14 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:44562 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S553814AbQLCAUz>;
	Sat, 2 Dec 2000 16:20:55 -0800
Received: (qmail 32542 invoked from network); 3 Dec 2000 00:20:47 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 3 Dec 2000 00:20:47 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@ocs.com.au>
To:     Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com>
cc:     Donald Becker <becker@scyld.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux 
In-reply-to: Your message of "Sat, 02 Dec 2000 13:07:29 MDT."
             <Pine.LNX.3.96.1001202130202.1450B-100000@mandrakesoft.mandrakesoft.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Sun, 03 Dec 2000 11:20:46 +1100
Message-ID: <2776.975802846@ocs3.ocs-net>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sat, 2 Dec 2000 13:07:29 -0600 (CST), 
Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com> wrote:
>If yes, my guess is correct, I think the proper solution is to:
>* create a generic set_config, which does nothing but convert the calls'
>semantics into ethtool semantics, and
>* add ethtool support to the specific driver

cc list trimmed.

If you go down this path, please add a standard performance monitoring
method to query the current capacity of an interface.  It is frustrating
to report "eth0 is handling 1 Megabyte/second, but we cannot tell if
that is 90% (10BaseT) or 9% (100BaseT) utilization".  We should report
capacity rather than speed because speed alone is not the controlling
factor, other things like half or full duplex affect the capacity.


From owner-netdev@oss.sgi.com Sat Dec  2 21:48:05 2000
Received:  by oss.sgi.com id <S553822AbQLCFrq>;
	Sat, 2 Dec 2000 21:47:46 -0800
Received: from a203-167-249-89.reverse.clear.net.nz ([203.167.249.89]:19204
        "HELO metastasis.f00f.org") by oss.sgi.com with SMTP
	id <S553744AbQLCFrQ>; Sat, 2 Dec 2000 21:47:16 -0800
Received: by metastasis.f00f.org (Postfix, from userid 1000)
	id A4D889DAA; Sun,  3 Dec 2000 18:47:12 +1300 (NZDT)
Date:   Sun, 3 Dec 2000 18:47:12 +1300
From:   Chris Wedgwood <cw@f00f.org>
To:     Philip Blundell <philb@gnu.org>
Cc:     Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com>,
        Donald Becker <becker@scyld.com>,
        Francois Romieu <romieu@cogenit.fr>,
        Russell King <rmk@arm.linux.org.uk>,
        Ivan Passos <lists@cyclades.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
Message-ID: <20001203184712.C1630@metastasis.f00f.org>
References: <Pine.LNX.3.96.1001202130202.1450B-100000@mandrakesoft.mandrakesoft.com> <jgarzik@mandrakesoft.mandrakesoft.com> <E142IrA-0007hG-00@kings-cross.london.uk.eu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <E142IrA-0007hG-00@kings-cross.london.uk.eu.org>; from philb@gnu.org on Sat, Dec 02, 2000 at 08:02:00PM +0000
X-No-Archive: Yes
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Does it? At which point? To me it looks like it calls dev->do_ioctl
or am I missing something?


  --cw


On Sat, Dec 02, 2000 at 08:02:00PM +0000, Philip Blundell wrote:
    >Does 'ifconfig eth0 media xxx' wind up calling dev->set_config?
    
    Yes.
    
    p.
    
    

From owner-netdev@oss.sgi.com Sun Dec  3 03:24:38 2000
Received:  by oss.sgi.com id <S553826AbQLCLY2>;
	Sun, 3 Dec 2000 03:24:28 -0800
Received: from tazenda.demon.co.uk ([158.152.220.239]:4612 "EHLO
        tazenda.demon.co.uk") by oss.sgi.com with ESMTP id <S553817AbQLCLYO>;
	Sun, 3 Dec 2000 03:24:14 -0800
Received: from kings-cross.london.uk.eu.org [::ffff:192.168.2.83] 
	by tazenda.demon.co.uk with esmtp (Exim 3.11 #1 (Debian))
	id 142X39-0007gd-00; Sun, 03 Dec 2000 11:11:19 +0000
Received: from localhost
	([::ffff:127.0.0.1] helo=tazenda.demon.co.uk ident=pb)
	by kings-cross.london.uk.eu.org with esmtp (Exim 3.12 #1 (Debian))
	id 142X2p-0003Kc-00; Sun, 03 Dec 2000 11:10:59 +0000
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To:     Chris Wedgwood <cw@f00f.org>
cc:     Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com>,
        Donald Becker <becker@scyld.com>,
        Francois Romieu <romieu@cogenit.fr>,
        Russell King <rmk@arm.linux.org.uk>,
        Ivan Passos <lists@cyclades.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux 
In-Reply-To: Message from Chris Wedgwood <cw@f00f.org> 
   of "Sun, 03 Dec 2000 18:47:12 +1300." <20001203184712.C1630@metastasis.f00f.org> 
References: <Pine.LNX.3.96.1001202130202.1450B-100000@mandrakesoft.mandrakesoft.com> <jgarzik@mandrakesoft.mandrakesoft.com> <E142IrA-0007hG-00@kings-cross.london.uk.eu.org>  <20001203184712.C1630@metastasis.f00f.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Sun, 03 Dec 2000 11:10:59 +0000
From:   Philip Blundell <philb@gnu.org>
Message-Id: <E142X2p-0003Kc-00@kings-cross.london.uk.eu.org>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>Does it? At which point? To me it looks like it calls dev->do_ioctl
>or am I missing something?

It uses SIOCSIFMAP, which (I think) winds up in dev.c here:

	case SIOCSIFMAP:
			if (dev->set_config) {
				if (!netif_device_present(dev))
					return -ENODEV;
				return dev->set_config(dev,&ifr->ifr_map);
			}
			return -EOPNOTSUPP;
	
p.



From owner-netdev@oss.sgi.com Sun Dec  3 03:28:38 2000
Received:  by oss.sgi.com id <S553828AbQLCL22>;
	Sun, 3 Dec 2000 03:28:28 -0800
Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:62982 "EHLO
        www.linux.org.uk") by oss.sgi.com with ESMTP id <S553825AbQLCL2W>;
	Sun, 3 Dec 2000 03:28:22 -0800
Received: from dyn-33.linux.theplanet.co.uk ([195.92.244.33] helo=caramon.arm.linux.org.uk)
	by www.linux.org.uk with esmtp (Exim 3.13 #1)
	id 142XJC-0000gr-00; Sun, 03 Dec 2000 11:27:55 +0000
Received: from flint.arm.linux.org.uk (IDENT:root@flint.arm.linux.org.uk [192.168.0.4])
	by caramon.arm.linux.org.uk (8.11.0/8.11.0) with ESMTP id eB3BRmd11795;
	Sun, 3 Dec 2000 11:27:48 GMT
Received: (from rmk@localhost)
	by flint.arm.linux.org.uk (8.11.0/8.11.0) id eB3BRm531079;
	Sun, 3 Dec 2000 11:27:48 GMT
From:   Russell King <rmk@arm.linux.org.uk>
Message-Id: <200012031127.eB3BRm531079@flint.arm.linux.org.uk>
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
To:     philb@gnu.org (Philip Blundell)
Date:   Sun, 3 Dec 2000 11:27:47 +0000 (GMT)
Cc:     cw@f00f.org (Chris Wedgwood), linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
In-Reply-To: <E142X2p-0003Kc-00@kings-cross.london.uk.eu.org> from "Philip Blundell" at Dec 03, 2000 11:10:59 AM
X-Location: london.england.earth.mulky-way.universe
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

(CC list trimmed)

Philip Blundell writes:
> >Does it? At which point? To me it looks like it calls dev->do_ioctl
> >or am I missing something?
> 
> It uses SIOCSIFMAP, which (I think) winds up in dev.c here:
> 
> 	case SIOCSIFMAP:
> 			if (dev->set_config) {
> 				if (!netif_device_present(dev))
> 					return -ENODEV;
> 				return dev->set_config(dev,&ifr->ifr_map);
> 			}
> 			return -EOPNOTSUPP;

It definitely does end up there.  However, the ethtool ioctls end up
in dev->do_ioctl.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rmk@arm.linux.org.uk      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

From owner-netdev@oss.sgi.com Sun Dec  3 05:43:59 2000
Received:  by oss.sgi.com id <S553832AbQLCNnj>;
	Sun, 3 Dec 2000 05:43:39 -0800
Received: from mandrakesoft.mandrakesoft.com ([216.71.84.35]:41248 "EHLO
        mandrakesoft.mandrakesoft.com") by oss.sgi.com with ESMTP
	id <S553829AbQLCNnW>; Sun, 3 Dec 2000 05:43:22 -0800
Received: from localhost (jgarzik@localhost)
	by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with SMTP id HAA23690;
	Sun, 3 Dec 2000 07:43:01 -0600
Date:   Sun, 3 Dec 2000 07:43:01 -0600 (CST)
From:   Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com>
To:     Keith Owens <kaos@ocs.com.au>
cc:     Donald Becker <becker@scyld.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux 
In-Reply-To: <2776.975802846@ocs3.ocs-net>
Message-ID: <Pine.LNX.3.96.1001203074055.23089B-100000@mandrakesoft.mandrakesoft.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sun, 3 Dec 2000, Keith Owens wrote:
> If you go down this path, please add a standard performance monitoring
> method to query the current capacity of an interface.
> to report "eth0 is handling 1 Megabyte/second, but we cannot tell if
> that is 90% (10BaseT) or 9% (100BaseT) utilization".  We should report
> capacity rather than speed because speed alone is not the controlling
> factor, other things like half or full duplex affect the capacity.

Well, ethtool interface supports reporting media selection as well as
[re]setting media setting.  I dunno if we could report what capacity
an interface is handling without adding code to hot paths...

	Jeff




From owner-netdev@oss.sgi.com Sun Dec  3 08:21:09 2000
Received:  by oss.sgi.com id <S553846AbQLCQU7>;
	Sun, 3 Dec 2000 08:20:59 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:20492 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553836AbQLCQUb>;
	Sun, 3 Dec 2000 08:20:31 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA23039; Sun, 3 Dec 2000 19:20:06 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012031620.TAA23039@ms2.inr.ac.ru>
Subject: Re: udpv6 multicast delivery on linux24 and linux22
To:     yoshfuji@ecei.tohoku.ac.JP (YOSHIFUJI Hideaki /
        =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=)
Date:   Sun, 3 Dec 2000 19:20:06 +0300 (MSK)
Cc:     netdev@oss.sgi.com
In-Reply-To: <20001201192636B.yoshfuji@ecei.tohoku.ac.jp> from "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" at Dec 1, 0 01:45:00 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 289       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Is this fix (for udpv6_mcast_deliver()) correct?

No doubts.


> I guess you're confusing similar code in ipv4/udp.c;
> order of arguments for udp_XX_mcast_next() is different between
> ipv6 and ipv4.

Indeed. And the order used by IP is difficult to call reasonable. 8)

Alexey

From owner-netdev@oss.sgi.com Sun Dec  3 12:29:49 2000
Received:  by oss.sgi.com id <S553850AbQLCU3j>;
	Sun, 3 Dec 2000 12:29:39 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:19724 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S553844AbQLCU3S>;
	Sun, 3 Dec 2000 12:29:18 -0800
Received: (qmail 4990 invoked from network); 3 Dec 2000 20:29:11 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 3 Dec 2000 20:29:11 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@ocs.com.au>
To:     Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com>
cc:     Donald Becker <becker@scyld.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux 
In-reply-to: Your message of "Sun, 03 Dec 2000 07:43:01 MDT."
             <Pine.LNX.3.96.1001203074055.23089B-100000@mandrakesoft.mandrakesoft.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Mon, 04 Dec 2000 07:29:10 +1100
Message-ID: <4778.975875350@ocs3.ocs-net>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sun, 3 Dec 2000 07:43:01 -0600 (CST), 
Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com> wrote:
>On Sun, 3 Dec 2000, Keith Owens wrote:
>> If you go down this path, please add a standard performance monitoring
>> method to query the current capacity of an interface.
>Well, ethtool interface supports reporting media selection as well as
>[re]setting media setting.  I dunno if we could report what capacity
>an interface is handling without adding code to hot paths...

You calculate the capacity during ifconfig up or during speed change.
That is not on the hot path.


From owner-netdev@oss.sgi.com Sun Dec  3 12:41:49 2000
Received:  by oss.sgi.com id <S553853AbQLCUla>;
	Sun, 3 Dec 2000 12:41:30 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:22540 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S553847AbQLCUlM>;
	Sun, 3 Dec 2000 12:41:12 -0800
Received: (qmail 5072 invoked from network); 3 Dec 2000 20:41:06 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 3 Dec 2000 20:41:06 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@ocs.com.au>
To:     Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com>,
        Donald Becker <becker@scyld.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux 
In-reply-to: Your message of "Mon, 04 Dec 2000 07:29:10 +1100."
             <4778.975875350@ocs3.ocs-net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Mon, 04 Dec 2000 07:41:06 +1100
Message-ID: <4910.975876066@ocs3.ocs-net>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, 04 Dec 2000 07:29:10 +1100, 
Keith Owens <kaos@ocs.com.au> wrote:
>On Sun, 3 Dec 2000 07:43:01 -0600 (CST), 
>Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com> wrote:
>>On Sun, 3 Dec 2000, Keith Owens wrote:
>>> If you go down this path, please add a standard performance monitoring
>>> method to query the current capacity of an interface.
>>Well, ethtool interface supports reporting media selection as well as
>>[re]setting media setting.  I dunno if we could report what capacity
>>an interface is handling without adding code to hot paths...
>
>You calculate the capacity during ifconfig up or during speed change.
>That is not on the hot path.

Replying to my own mail, I just realised it was ambiguous.  By "current
capacity" I mean the maximum capacity of the link based on the current
settings.  We can get capacity _used_ from the byte counters, we do not
have a figure for maximum capacity.


From owner-netdev@oss.sgi.com Mon Dec  4 21:59:05 2000
Received:  by oss.sgi.com id <S553715AbQLEF6p>;
	Mon, 4 Dec 2000 21:58:45 -0800
Received: from main.cyclades.com ([209.128.87.2]:65029 "EHLO cyclades.com")
	by oss.sgi.com with ESMTP id <S553690AbQLEF6m>;
	Mon, 4 Dec 2000 21:58:42 -0800
Received: from localhost (lists@localhost)
	by cyclades.com (8.9.3/8.9.3) with ESMTP id VAA08021;
	Mon, 4 Dec 2000 21:58:29 -0800
Date:   Mon, 4 Dec 2000 21:58:29 -0800 (PST)
From:   Ivan Passos <lists@cyclades.com>
To:     Linux Kernel List <linux-kernel@vger.kernel.org>
cc:     Philip Blundell <philb@gnu.org>, netdev@oss.sgi.com
Subject: [RFC-2] Configuring Synchronous Interfaces in Linux
Message-ID: <Pine.LNX.4.10.10012042135090.5269-100000@main.cyclades.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Hello,

Thanks to all of you who responded to my first RFC on this subject. The
discussion ended up going in the Ethernet direction, and I frankly don't
know whether that applies to this case, or even if it _should_ apply or
they should really be separate config. subsystems. This is another thing
that you may wanna throw your opinions on.

Anyhow, the parameters we currently need to configure on our board (the
PC300) are as follows:

- Media: V.35, RS-232, X.21, T1, E1
- Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
            already supported by the 'hw' option)
- Clock: 'ext' (or 0, which implies external clock) or some numeric value
         > 0 (which implies internal clock); setting it to 'int' would set
         it to some fixed numeric value > 0 (useful for T1/E1 links, just
         to indicate master clock as opposed to slave or 'ext' clock) 
- Frame Relay only: 
	- End type: DCE or DTE (maybe this applies to other interface
                    types as well)
	- DLCI: DLC number for the interface
- T1/E1 only:
	- Line code: 
	- Frame mode:
	- LBO (T1 only): line-build-out
	- Rx Sensitivity: short-haul or long-haul
	- Active channels: mask that represents the possible 24/32
                           channels (timeslots) on a T1/E1 line

I'm sure that _all_ the other sync cards need to configure the _same_
parameters (or a subset of them), and there may be cards that need even
more parameters (but we have to start somewhere ... ;). So having a
unified interface and making the drivers compliant to it is not that hard
and surely would help users to dump the currently ridiculous set of
individual config. tools for these cards (yes, we currently have our own
pc300cfg, along with the -- not absolute -- "standard" sethdlc utility).

I'm willing to go for this implementation, but I wanted to know first:
- whether ifconfig is the right place to do it;
- where I should create the new ioctl's to handle these new parameters.

Suggestions / comments are more than welcome.

Later,
Ivan


From owner-netdev@oss.sgi.com Tue Dec  5 01:39:05 2000
Received:  by oss.sgi.com id <S553965AbQLEJi4>;
	Tue, 5 Dec 2000 01:38:56 -0800
Received: from se1.cogenit.fr ([195.68.53.173]:5905 "EHLO se1.cogenit.fr")
	by oss.sgi.com with ESMTP id <S553962AbQLEJis>;
	Tue, 5 Dec 2000 01:38:48 -0800
Received: (from romieu@localhost)
	by se1.cogenit.fr (8.11.1/8.11.1) id eB59cFW26668;
	Tue, 5 Dec 2000 10:38:15 +0100
Date:   Tue, 5 Dec 2000 10:38:15 +0100
From:   Francois Romieu <romieu@cogenit.fr>
To:     Ivan Passos <lists@cyclades.com>
Cc:     Linux Kernel List <linux-kernel@vger.kernel.org>,
        Philip Blundell <philb@gnu.org>, netdev@oss.sgi.com
Subject: Re: [RFC-2] Configuring Synchronous Interfaces in Linux
Message-ID: <20001205103815.A25405@se1.cogenit.fr>
References: <Pine.LNX.4.10.10012042135090.5269-100000@main.cyclades.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <Pine.LNX.4.10.10012042135090.5269-100000@main.cyclades.com>
X-Organisation: Marie's fan club
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Ivan Passos <lists@cyclades.com> écrit :
[...]
> Anyhow, the parameters we currently need to configure on our board (the
> PC300) are as follows:
> 
> - Media: V.35, RS-232, X.21, T1, E1

drivers/net/wan/lmc/lmc_media.c:65
char *lmc_t1_cables[] = {
  "V.10/RS423", "EIA530A", "reserved", "X.21", "V.35",
  "EIA449/EIA530/V.36", "V.28/EIA232", "none", NULL
};
(Where it's used btw).
I don't exactly see the point here: do some of your cards supports these
media at the same time ? I would have believed it to be set in stone.

> - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
>             already supported by the 'hw' option)

+ Transparent HDLC ?

> - Clock: 'ext' (or 0, which implies external clock) or some numeric value
>          > 0 (which implies internal clock); setting it to 'int' would set
>          it to some fixed numeric value > 0 (useful for T1/E1 links, just
>          to indicate master clock as opposed to slave or 'ext' clock) 

Ok.

[...]
> - T1/E1 only:
> 	- Line code: 
> 	- Frame mode:
> 	- LBO (T1 only): line-build-out
> 	- Rx Sensitivity: short-haul or long-haul
> 	- Active channels: mask that represents the possible 24/32
>                            channels (timeslots) on a T1/E1 line

May I ask what kind of protocol support you have in mind here ?

> I'm sure that _all_ the other sync cards need to configure the _same_
> parameters (or a subset of them), and there may be cards that need even
> more parameters (but we have to start somewhere ... ;). So having a
> unified interface and making the drivers compliant to it is not that hard
> and surely would help users to dump the currently ridiculous set of
> individual config. tools for these cards (yes, we currently have our own
> pc300cfg, along with the -- not absolute -- "standard" sethdlc utility).
> 
> I'm willing to go for this implementation, but I wanted to know first:
> - whether ifconfig is the right place to do it;

We can pass (media/clock) through his "media" parameter but I won't claim it
to be sexy. So far, I don't see how we may avoid some tool to do all the
required ioctl. 

> - where I should create the new ioctl's to handle these new parameters.

drivers/net/wan/sbni.[ch] uses the SIOCDEVPRIVATE range for different things.
The x25 protocol uses the SIOCPROTOPRIVATE. I'd rather avoid both.

> Suggestions / comments are more than welcome.

-- 
Ueimor

From owner-netdev@oss.sgi.com Tue Dec  5 01:43:06 2000
Received:  by oss.sgi.com id <S553967AbQLEJm4>;
	Tue, 5 Dec 2000 01:42:56 -0800
Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:37232 "EHLO
        the-village.bc.nu") by oss.sgi.com with ESMTP id <S553964AbQLEJml>;
	Tue, 5 Dec 2000 01:42:41 -0800
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 143Ebi-000500-00; Tue, 5 Dec 2000 09:41:54 +0000
Subject: Re: [RFC-2] Configuring Synchronous Interfaces in Linux
To:     lists@cyclades.com (Ivan Passos)
Date:   Tue, 5 Dec 2000 09:41:53 +0000 (GMT)
Cc:     linux-kernel@vger.kernel.org (Linux Kernel List),
        philb@gnu.org (Philip Blundell), netdev@oss.sgi.com
In-Reply-To: <Pine.LNX.4.10.10012042135090.5269-100000@main.cyclades.com> from "Ivan Passos" at Dec 04, 2000 09:58:29 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E143Ebi-000500-00@the-village.bc.nu>
From:   Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

> - Media: V.35, RS-232, X.21, T1, E1
		DS1, DS3, ...

> - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
>             already supported by the 'hw' option)

Not nicely. 

> - Clock: 'ext' (or 0, which implies external clock) or some numeric value
>          > 0 (which implies internal clock); setting it to 'int' would set
>          it to some fixed numeric value > 0 (useful for T1/E1 links, just
>          to indicate master clock as opposed to slave or 'ext' clock) 

Yep

> I'm sure that _all_ the other sync cards need to configure the _same_
> parameters (or a subset of them), and there may be cards that need even

And more

Generic Z85x30 drivers can run with multiple framing CRC versions (all the
chip can do in theory). So I think you need

	bitcoding		[NRZ, NRZI]
	crctype			CRC16, ...
	hunt

> I'm willing to go for this implementation, but I wanted to know first:
> - whether ifconfig is the right place to do it;
> - where I should create the new ioctl's to handle these new parameters.

I think a new ioctl would be sensible. There is a lot to go in it. 


From owner-netdev@oss.sgi.com Tue Dec  5 06:49:45 2000
Received:  by oss.sgi.com id <S553717AbQLEOt0>;
	Tue, 5 Dec 2000 06:49:26 -0800
Received: from pak145.pakuni.net ([205.138.121.145]:42748 "EHLO
        postal.paktronix.com") by oss.sgi.com with ESMTP id <S553692AbQLEOtB>;
	Tue, 5 Dec 2000 06:49:01 -0800
Received: from netmonster.pakint.net (netmonster [192.168.3.13])
	by postal.paktronix.com (8.9.3/8.9.3) with ESMTP id JAA30298;
	Tue, 5 Dec 2000 09:21:15 -0600
Date:   Tue, 5 Dec 2000 08:43:27 -0600 (CST)
From:   "Matthew G. Marsh" <mgm@paktronix.com>
X-Sender: mgm@netmonster.pakint.net
To:     Ivan Passos <lists@cyclades.com>
cc:     Linux Kernel List <linux-kernel@vger.kernel.org>,
        netdev@oss.sgi.com
Subject: Re: [RFC-2] Configuring Synchronous Interfaces in Linux
In-Reply-To: <Pine.LNX.4.10.10012042135090.5269-100000@main.cyclades.com>
Message-ID: <Pine.LNX.4.10.10012050835370.1199-100000@netmonster.pakint.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, 4 Dec 2000, Ivan Passos wrote:

> Hello,

[snip details...]
 
> I'm willing to go for this implementation, but I wanted to know first:
> - whether ifconfig is the right place to do it;

I would like to note an objection to using ifconfig to carry all of this.
For example I do not use or even have ifconfig on any of my systems as I
only use/need/want Alexey's ip utility to perform all of those tasks. 

I would rather have an independant utility that could set and check the
settings of all of these variables for whatever classes of networking
connections existed. This would provide a cleaner split between the
protocol configuration (IPv4, IPv6, IPX, ...) and the device (V.##,
10/100, 4/16/100, etc) parameters. 

Such a split should make for a cleaner configuration structure WRT virtual
devices as well which for the most part deal with the protocol config and
do not need much device config. 

FWIW: Alexey's ip has replaced both ifconfig and route on my systems.
Something that could now replace having several different card config
utils around with one binary would be fantastic.

> - where I should create the new ioctl's to handle these new parameters.
> 
> Suggestions / comments are more than welcome.
> 
> Later,
> Ivan

Thanks! I will volunteer to test/break/etc as my coding skills verge
beyond ludicrous. 

--------------------------------------------------
Matthew G. Marsh,  President
Paktronix Systems LLC
1506 North 59th Street
Omaha  NE  68104
Phone: (402) 932-7250
Email: mgm@paktronix.com
WWW:  http://www.paktronix.com
--------------------------------------------------




From owner-netdev@oss.sgi.com Tue Dec  5 07:16:05 2000
Received:  by oss.sgi.com id <S553967AbQLEPP4>;
	Tue, 5 Dec 2000 07:15:56 -0800
Received: from ihemail1.lucent.com ([192.11.222.161]:27337 "EHLO
        ihemail1.firewall.lucent.com") by oss.sgi.com with ESMTP
	id <S553715AbQLEPPe>; Tue, 5 Dec 2000 07:15:34 -0800
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA25838
	for <netdev@oss.sgi.com>; Tue, 5 Dec 2000 10:15:28 -0500 (EST)
Received: from metros1.ral.lucent.com (h135-92-100-10.lucent.com [135.92.100.10])
	by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA25828
	for <netdev@oss.sgi.com>; Tue, 5 Dec 2000 10:15:27 -0500 (EST)
Received: from lucent.com ([135.92.105.81]) by
          metros1.ral.lucent.com (Netscape Messaging Server 4.15) with
          ESMTP id G53P1R00.40J; Tue, 5 Dec 2000 10:15:27 -0500 
Message-ID: <3A2D068E.604FE486@lucent.com>
Date:   Tue, 05 Dec 2000 10:15:26 -0500
From:   gparrott@lucent.com (Greg Parrott)
Organization: Lucent Technologies - Optical Area Networks
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To:     Linux Kernel List <linux-kernel@vger.kernel.org>
CC:     netdev@oss.sgi.com
Subject: Re: [RFC-2] Configuring Synchronous Interfaces in Linux
References: <E143Ebi-000500-00@the-village.bc.nu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

I have a vested interest in how this all turns out.  I own a Packet Over SONET
device driver for our OC-12 and OC-48 NICs that I currently pass all parameters
to the driver via arguments on the insmod.  To avoid lengthy commands, we
provide the common defaults.  We accept some basic ifconfig input, but with
SONET/SDH and chip specific items that needed to be controlled, ifconfig did not
seem the way to go.

Thanks!

Greg
--
Greg Parrott
Lucent Technologies, Inc.
Optical Area Networking
(919) 838-6095
http://www.lucent-optical.com/oan


Alan Cox wrote:

> > - Media: V.35, RS-232, X.21, T1, E1
>                 DS1, DS3, ...
>
> > - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
> >             already supported by the 'hw' option)
>
> Not nicely.
>
> > - Clock: 'ext' (or 0, which implies external clock) or some numeric value
> >          > 0 (which implies internal clock); setting it to 'int' would set
> >          it to some fixed numeric value > 0 (useful for T1/E1 links, just
> >          to indicate master clock as opposed to slave or 'ext' clock)
>
> Yep
>
> > I'm sure that _all_ the other sync cards need to configure the _same_
> > parameters (or a subset of them), and there may be cards that need even
>
> And more
>
> Generic Z85x30 drivers can run with multiple framing CRC versions (all the
> chip can do in theory). So I think you need
>
>         bitcoding               [NRZ, NRZI]
>         crctype                 CRC16, ...
>         hunt
>
> > I'm willing to go for this implementation, but I wanted to know first:
> > - whether ifconfig is the right place to do it;
> > - where I should create the new ioctl's to handle these new parameters.
>
> I think a new ioctl would be sensible. There is a lot to go in it.


From owner-netdev@oss.sgi.com Tue Dec  5 07:56:36 2000
Received:  by oss.sgi.com id <S553977AbQLEP40>;
	Tue, 5 Dec 2000 07:56:26 -0800
Received: from robur.slu.se ([130.238.98.12]:5643 "EHLO robur.slu.se")
	by oss.sgi.com with ESMTP id <S553962AbQLEP4D>;
	Tue, 5 Dec 2000 07:56:03 -0800
Received: (from robert@localhost) by robur.slu.se (8.8.7/8.8.7) id QAA00906; Tue, 5 Dec 2000 16:55:48 +0100
From:   Robert Olsson <Robert.Olsson@data.slu.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14893.4100.310894.704516@robur.slu.se>
Date:   Tue, 5 Dec 2000 16:55:48 +0100 (CET)
To:     gparrott@lucent.com (Greg Parrott)
Cc:     netdev@oss.sgi.com
Subject: Re: [RFC-2] Configuring Synchronous Interfaces in Linux
In-Reply-To: <3A2D068E.604FE486@lucent.com>
References: <E143Ebi-000500-00@the-village.bc.nu>
	<3A2D068E.604FE486@lucent.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Offtopic.

And I was happy being able to saturate an OC-48 Link with four Linux boxes
equipped with GIGE. :-) 1440 byte packets and a combination of three acenic's 
and one e1000 NIC.

(Cisco output)

POS1/0 is up, line protocol is up
  Hardware is Packet over SONET
  Description: STM16 connection to STK-PR-2
  Internet address is XXX.XXX.XXX.XXX/MM
  MTU 4470 bytes, BW 2400000 Kbit, DLY 100 usec, rely 255/255, load 255/255
  Encapsulation HDLC, crc 32, loopback not set
  Keepalive set (10 sec)
  Scramble enabled
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 01:02:17
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  30 second input rate 7000 bits/sec, 4 packets/sec
  30 second output rate 2400361000 bits/sec, 210413 packets/sec
                        ^^^^^^^^^^^^^^^^^^
     185427805 packets input, 2538532250 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
              0 parity
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     1106539583 packets output, 1462397823 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

						--ro

Greg Parrott writes:
 > I have a vested interest in how this all turns out.  I own a Packet Over SONET
 > device driver for our OC-12 and OC-48 NICs that I currently pass all parameters
 > to the driver via arguments on the insmod.  To avoid lengthy commands, we
 > provide the common defaults.  We accept some basic ifconfig input, but with
 > SONET/SDH and chip specific items that needed to be controlled, ifconfig did not
 > seem the way to go.

From owner-netdev@oss.sgi.com Tue Dec  5 11:18:46 2000
Received:  by oss.sgi.com id <S554027AbQLETS1>;
	Tue, 5 Dec 2000 11:18:27 -0800
Received: from main.cyclades.com ([209.128.87.2]:43017 "EHLO cyclades.com") convert rfc822-to-8bit
	by oss.sgi.com with ESMTP id <S554007AbQLETR7>;
	Tue, 5 Dec 2000 11:17:59 -0800
Received: from localhost (lists@localhost)
	by cyclades.com (8.9.3/8.9.3) with ESMTP id LAA05556;
	Tue, 5 Dec 2000 11:17:57 -0800
Date:   Tue, 5 Dec 2000 11:17:57 -0800 (PST)
From:   Ivan Passos <lists@cyclades.com>
To:     Linux Kernel List <linux-kernel@vger.kernel.org>
cc:     netdev@oss.sgi.com
Subject: Re: [RFC-2] Configuring Synchronous Interfaces in Linux
In-Reply-To: <20001205103815.A25405@se1.cogenit.fr>
Message-ID: <Pine.LNX.4.10.10012051110360.1713-100000@main.cyclades.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


On Tue, 5 Dec 2000, Francois Romieu wrote:

> Ivan Passos <lists@cyclades.com> écrit :
> > 
> > - Media: V.35, RS-232, X.21, T1, E1
> 
> I don't exactly see the point here: do some of your cards supports these
> media at the same time ? I would have believed it to be set in stone.

Yes. The PC300/RSV supports RS-232 and V.35, software selectable. The
PC300/TE supports T1 and E1, also software selectable.

> > - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
> >             already supported by the 'hw' option)
> 
> + Transparent HDLC ?

As I said, for sure there will be parameters left out, but this would be
my _initial_ set of parameters. Subsequent patches would add more and more
parameters.

> > - T1/E1 only:
> > 	- Line code: 
> > 	- Frame mode:
> > 	- LBO (T1 only): line-build-out
> > 	- Rx Sensitivity: short-haul or long-haul
> > 	- Active channels: mask that represents the possible 24/32
> >                            channels (timeslots) on a T1/E1 line
> 
> May I ask what kind of protocol support you have in mind here ?

Same protocols as before: Frame Relay, X.25, PPP, HDLC ... Did I
misunderstood your question??

> We can pass (media/clock) through his "media" parameter but I won't claim it
> to be sexy. So far, I don't see how we may avoid some tool to do all the
> required ioctl. 

The point is not to prevent the tool from doing ioctl's, is having _one
single_ tool that generates _the same_ ioctl to all sync drivers. That
would mean that a user wouldn't care if his sync card is from X, Y or Z
manufacturer, the command syntax to set a specific link configuration
would be the same for all of them. How to translate this standard command
to the hardware, that's a device driver problem (no news here).

> > - where I should create the new ioctl's to handle these new parameters.
> 
> drivers/net/wan/sbni.[ch] uses the SIOCDEVPRIVATE range for different things.
> The x25 protocol uses the SIOCPROTOPRIVATE. I'd rather avoid both.

That's what everybody does currently, but each driver uses their _own_ set
of ioctl's. Having one unified set of ioctl's for all drivers would ease
the user's life a lot.

Later,
Ivan


From owner-netdev@oss.sgi.com Tue Dec  5 11:24:16 2000
Received:  by oss.sgi.com id <S554014AbQLETX4>;
	Tue, 5 Dec 2000 11:23:56 -0800
Received: from main.cyclades.com ([209.128.87.2]:46857 "EHLO cyclades.com")
	by oss.sgi.com with ESMTP id <S553675AbQLETXx>;
	Tue, 5 Dec 2000 11:23:53 -0800
Received: from localhost (lists@localhost)
	by cyclades.com (8.9.3/8.9.3) with ESMTP id LAA27526;
	Tue, 5 Dec 2000 11:23:50 -0800
Date:   Tue, 5 Dec 2000 11:23:50 -0800 (PST)
From:   Ivan Passos <lists@cyclades.com>
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>
cc:     Linux Kernel List <linux-kernel@vger.kernel.org>,
        netdev@oss.sgi.com
Subject: Re: [RFC-2] Configuring Synchronous Interfaces in Linux
In-Reply-To: <E143Ebi-000500-00@the-village.bc.nu>
Message-ID: <Pine.LNX.4.10.10012051118140.1713-100000@main.cyclades.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


On Tue, 5 Dec 2000, Alan Cox wrote:
> 
> I think a new ioctl would be sensible. There is a lot to go in it. 

Alan, what's the approach you'd feel more comfortable with:
- One ioctl that passes a pointer to a known structure in ifr.ifr_data as 
  its argument.
- Several ioctl's, one for each parameter, that pass only the specific 
  parameter new value as the argument.

The former is good because it relies on a _single_ ioctl. However, every
time you change the ioctl structure you may lose backward compatibility.

The latter is good because new implementations / features won't affect
previous working features. However, it'd create a huge list of ioctl's.

Please let me know whatcha think.

Later,
Ivan


From owner-netdev@oss.sgi.com Tue Dec  5 11:40:36 2000
Received:  by oss.sgi.com id <S553962AbQLETk0>;
	Tue, 5 Dec 2000 11:40:26 -0800
Received: from main.cyclades.com ([209.128.87.2]:57097 "EHLO cyclades.com")
	by oss.sgi.com with ESMTP id <S553692AbQLETkG>;
	Tue, 5 Dec 2000 11:40:06 -0800
Received: from localhost (lists@localhost)
	by cyclades.com (8.9.3/8.9.3) with ESMTP id LAA12335;
	Tue, 5 Dec 2000 11:40:02 -0800
Date:   Tue, 5 Dec 2000 11:40:02 -0800 (PST)
From:   Ivan Passos <lists@cyclades.com>
To:     "Matthew G. Marsh" <mgm@paktronix.com>
cc:     Linux Kernel List <linux-kernel@vger.kernel.org>,
        netdev@oss.sgi.com
Subject: Re: [RFC-2] Configuring Synchronous Interfaces in Linux
In-Reply-To: <Pine.LNX.4.10.10012050835370.1199-100000@netmonster.pakint.net>
Message-ID: <Pine.LNX.4.10.10012051138490.1713-100000@main.cyclades.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


On Tue, 5 Dec 2000, Matthew G. Marsh wrote:
> 
> I would like to note an objection to using ifconfig to carry all of this.
> For example I do not use or even have ifconfig on any of my systems as I
> only use/need/want Alexey's ip utility to perform all of those tasks. 
> 
> I would rather have an independant utility that could set and check the
> settings of all of these variables for whatever classes of networking
> connections existed. This would provide a cleaner split between the
> protocol configuration (IPv4, IPv6, IPX, ...) and the device (V.##,
> 10/100, 4/16/100, etc) parameters. 
> 
> Such a split should make for a cleaner configuration structure WRT virtual
> devices as well which for the most part deal with the protocol config and
> do not need much device config. 
> 
> FWIW: Alexey's ip has replaced both ifconfig and route on my systems.
> Something that could now replace having several different card config
> utils around with one binary would be fantastic.

Very good point IMHO. I'll have a look at ip to see if I can get ideas
from it. Thanks for the info!!

Later,
Ivan


From owner-netdev@oss.sgi.com Tue Dec  5 11:47:36 2000
Received:  by oss.sgi.com id <S554068AbQLETrR>;
	Tue, 5 Dec 2000 11:47:17 -0800
Received: from main.cyclades.com ([209.128.87.2]:64009 "EHLO cyclades.com")
	by oss.sgi.com with ESMTP id <S553717AbQLETrA>;
	Tue, 5 Dec 2000 11:47:00 -0800
Received: from localhost (lists@localhost)
	by cyclades.com (8.9.3/8.9.3) with ESMTP id LAA07654;
	Tue, 5 Dec 2000 11:46:51 -0800
Date:   Tue, 5 Dec 2000 11:46:49 -0800 (PST)
From:   Ivan Passos <lists@cyclades.com>
To:     Mark Cooke <mpc@star.sr.bham.ac.uk>
cc:     Linux Kernel List <linux-kernel@vger.kernel.org>,
        netdev@oss.sgi.com
Subject: Re: [RFC-2] Configuring Synchronous Interfaces in Linux
In-Reply-To: <Pine.LNX.4.30.0012051925330.6718-100000@pc24.sr.bham.ac.uk>
Message-ID: <Pine.LNX.4.10.10012051141200.1713-100000@main.cyclades.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


On Tue, 5 Dec 2000, Mark Cooke wrote:
> 
> struct foo {
> 	unsigned int	crufty_compatability_number;
> 	.
> 	.
> 	.
> };
> 
>  ?

The problem is not this, but structure alignment and copy_[to|from]_user
operations. This approach, although it's my preferred one (due to being
self-contained), requires synchronization between kernel and utility, and
this sometimes is not always true.

Anyhow, I still prefer this approach over the "tons of different ioctl's"
one. I'd like to get the opinion of the community though (especially
Alan).

Later,
Ivan


From owner-netdev@oss.sgi.com Tue Dec  5 12:43:07 2000
Received:  by oss.sgi.com id <S554073AbQLEUm5>;
	Tue, 5 Dec 2000 12:42:57 -0800
Received: from wire.cadcamlab.org ([156.26.20.181]:54277 "EHLO
        wire.cadcamlab.org") by oss.sgi.com with ESMTP id <S553977AbQLEUmh>;
	Tue, 5 Dec 2000 12:42:37 -0800
Received: from peter by wire.cadcamlab.org with local (Exim 3.16 #1 (Debian))
	id 143Ou4-0008Gh-00; Tue, 05 Dec 2000 20:41:32 +0000
Date:   Tue, 5 Dec 2000 14:41:32 -0600
To:     Ivan Passos <lists@cyclades.com>
Cc:     Alan Cox <alan@lxorguk.ukuu.org.uk>,
        Linux Kernel List <linux-kernel@vger.kernel.org>,
        netdev@oss.sgi.com
Subject: Re: [RFC-2] Configuring Synchronous Interfaces in Linux
Message-ID: <20001205144132.D6567@cadcamlab.org>
References: <E143Ebi-000500-00@the-village.bc.nu> <Pine.LNX.4.10.10012051118140.1713-100000@main.cyclades.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.10.10012051118140.1713-100000@main.cyclades.com>; from lists@cyclades.com on Tue, Dec 05, 2000 at 11:23:50AM -0800
From:   Peter Samuelson <peter@cadcamlab.org>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


[Ivan Passos]
> - One ioctl that passes a pointer to a known structure in
>   ifr.ifr_data as its argument.

struct sync_params_ioctl_data {
  int opcode;
  union {......

Seems straightforward to me.  Basically just ioctl numbers within ioctl
numbers.

Peter

From owner-netdev@oss.sgi.com Tue Dec  5 13:54:58 2000
Received:  by oss.sgi.com id <S554089AbQLEVyi>;
	Tue, 5 Dec 2000 13:54:38 -0800
Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:15108 "EHLO
        the-village.bc.nu") by oss.sgi.com with ESMTP id <S554068AbQLEVyY>;
	Tue, 5 Dec 2000 13:54:24 -0800
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 143Q4I-0000EZ-00; Tue, 5 Dec 2000 21:56:11 +0000
Subject: Re: [RFC-2] Configuring Synchronous Interfaces in Linux
To:     lists@cyclades.com (Ivan Passos)
Date:   Tue, 5 Dec 2000 21:56:08 +0000 (GMT)
Cc:     alan@lxorguk.ukuu.org.uk (Alan Cox),
        linux-kernel@vger.kernel.org (Linux Kernel List),
        netdev@oss.sgi.com
In-Reply-To: <Pine.LNX.4.10.10012051118140.1713-100000@main.cyclades.com> from "Ivan Passos" at Dec 05, 2000 11:23:50 AM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E143Q4I-0000EZ-00@the-village.bc.nu>
From:   Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

> Alan, what's the approach you'd feel more comfortable with:
> - One ioctl that passes a pointer to a known structure in ifr.ifr_data as 
>   its argument.
> - Several ioctl's, one for each parameter, that pass only the specific 
>   parameter new value as the argument.
> 
> The former is good because it relies on a _single_ ioctl. However, every
> time you change the ioctl structure you may lose backward compatibility.

One ioctl with a set of subcommands seems to be quite common


From owner-netdev@oss.sgi.com Thu Dec  7 00:45:18 2000
Received:  by oss.sgi.com id <S553781AbQLGIo7>;
	Thu, 7 Dec 2000 00:44:59 -0800
Received: from a203-167-249-89.reverse.clear.net.nz ([203.167.249.89]:63236
        "HELO metastasis.f00f.org") by oss.sgi.com with SMTP
	id <S553772AbQLGIop>; Thu, 7 Dec 2000 00:44:45 -0800
Received: by metastasis.f00f.org (Postfix, from userid 1000)
	id BE6E29DA9; Thu,  7 Dec 2000 21:44:36 +1300 (NZDT)
Date:   Thu, 7 Dec 2000 21:44:36 +1300
From:   Chris Wedgwood <cw@f00f.org>
To:     Donald Becker <becker@scyld.com>
Cc:     Francois Romieu <romieu@cogenit.fr>,
        Russell King <rmk@arm.linux.org.uk>,
        Ivan Passos <lists@cyclades.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [RFC] Configuring synchronous interfaces in Linux
Message-ID: <20001207214436.A7974@metastasis.f00f.org>
References: <20001203075958.A1121@metastasis.f00f.org> <Pine.LNX.4.10.10012021412560.16980-100000@vaio.greennet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.10.10012021412560.16980-100000@vaio.greennet>; from becker@scyld.com on Sat, Dec 02, 2000 at 02:48:10PM -0500
X-No-Archive: Yes
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sat, Dec 02, 2000 at 02:48:10PM -0500, Donald Becker wrote:

    It's certainly possible to break the driver up, but it will be
    even more of a problem to maintain.  Some of the complicated
    media selection code applies to several generations.  Splitting
    the driver to have a copy for each generation means a lot of
    duplicated code, which quickly leads to version skew.

So how does someone, like me for example, try to cleanly add support
for something like ethtool when the only hardware they have is say
3c920 and they could care less about the rest?

The best thing I can see to do is to restructure the driver as is and
try to get common paths for things like media setting and remove the
module parameter hacks we now have; that way it should be possible to
add ethtool support that works for everything...

... how does that sound?



  --cw

P.S. Also, since only _two_ drivers actually support ethtool (hme and
     acenic) is everyone 100% happy they want this API? Surely now is
     the best time to invite discussion and promote ideas if people
     have requirements that ethtool can't satisfy?

From owner-netdev@oss.sgi.com Thu Dec 14 10:10:50 2000
Received:  by oss.sgi.com id <S553736AbQLNSKl>;
	Thu, 14 Dec 2000 10:10:41 -0800
Received: from mail.zmailer.org ([194.252.70.162]:62726 "EHLO zmailer.org")
	by oss.sgi.com with ESMTP id <S553711AbQLNSKS>;
	Thu, 14 Dec 2000 10:10:18 -0800
Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@zmailer.org))
	by mail.zmailer.org id <S2622039AbQLNSKH>;
	Thu, 14 Dec 2000 20:10:07 +0200
Date:	Thu, 14 Dec 2000 20:10:07 +0200
From:	Matti Aarnio <matti.aarnio@zmailer.org>
To:	netdev@oss.sgi.com
Subject: IGMPv3 for Linux ?
Message-ID: <20001214201007.O28963@mea-ext.zmailer.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi,

  Is anybody aware of 

http://www.sprintlabs.com/Department/IP-Interworking/Multicast/linux-igmpv3/

(Source Specific Multicast things for LAN-internal IGMP handling.)
(I think I got that URL right, but the site isn't answering to me.)

/Matti Aarnio

From owner-netdev@oss.sgi.com Thu Dec 14 10:56:11 2000
Received:  by oss.sgi.com id <S553753AbQLNSzv>;
	Thu, 14 Dec 2000 10:55:51 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:48391 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553742AbQLNSzg>;
	Thu, 14 Dec 2000 10:55:36 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA02730; Thu, 14 Dec 2000 21:51:26 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012141851.VAA02730@ms2.inr.ac.ru>
Subject: Re: IGMPv3 for Linux ?
To:     matti.aarnio@zmailer.ORG (Matti Aarnio)
Date:   Thu, 14 Dec 2000 21:51:26 +0300 (MSK)
Cc:     netdev@oss.sgi.com
In-Reply-To: <20001214201007.O28963@mea-ext.zmailer.org> from "Matti Aarnio" at Dec 14, 0 09:15:01 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 484       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

>   Is anybody aware of 
> 
> http://www.sprintlabs.com/Department/IP-Interworking/Multicast/linux-igmpv3/
> 
> (Source Specific Multicast things for LAN-internal IGMP handling.)
> (I think I got that URL right, but the site isn't answering to me.)

Probably, it is temorary failure. I have patch from them dated by
August 12.

I put it to ftp, if you will not succeed.
ftp://ftp.inr.ac.ru/private/linux-igmpv3-2.4.0-test3-080400.patch.gz
(directory is not readable)

Alexey


From owner-netdev@oss.sgi.com Thu Dec 14 13:18:31 2000
Received:  by oss.sgi.com id <S553764AbQLNVSM>;
	Thu, 14 Dec 2000 13:18:12 -0800
Received: from mail.zmailer.org ([194.252.70.162]:64262 "EHLO zmailer.org")
	by oss.sgi.com with ESMTP id <S553760AbQLNVRx>;
	Thu, 14 Dec 2000 13:17:53 -0800
Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@zmailer.org))
	by mail.zmailer.org id <S2622039AbQLNVRj>;
	Thu, 14 Dec 2000 23:17:39 +0200
Date:	Thu, 14 Dec 2000 23:17:38 +0200
From:	Matti Aarnio <matti.aarnio@zmailer.org>
To:	kuznet@ms2.inr.ac.ru
Cc:	Matti Aarnio <matti.aarnio@zmailer.ORG>, netdev@oss.sgi.com
Subject: Re: IGMPv3 for Linux ?
Message-ID: <20001214231738.P28963@mea-ext.zmailer.org>
References: <20001214201007.O28963@mea-ext.zmailer.org> <200012141851.VAA02730@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200012141851.VAA02730@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Thu, Dec 14, 2000 at 09:51:26PM +0300
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Thu, Dec 14, 2000 at 09:51:26PM +0300, kuznet@ms2.inr.ac.ru wrote:
> Hello!
> >   Is anybody aware of 
> > 
> > http://www.sprintlabs.com/Department/IP-Interworking/Multicast/linux-igmpv3/
> > 
> > (Source Specific Multicast things for LAN-internal IGMP handling.)
> 
> I have patch from them dated by August 12.

	During the IETF mboned session where I noticed that
	one, also a mention about its deficiency was made;
	namely, it breaks IGMPv2 as implemented at Linux.
	Improved version which has all IGMPs 1-thru-3
	working would be very much in order.

> Alexey

/Matti Aarnio

From owner-netdev@oss.sgi.com Fri Dec 15 00:28:50 2000
Received:  by oss.sgi.com id <S553772AbQLOI2a>;
	Fri, 15 Dec 2000 00:28:30 -0800
Received: from [192.71.57.4] ([192.71.57.4]:21519 "EHLO mail.framkom.se")
	by oss.sgi.com with ESMTP id <S553780AbQLOI2V>;
	Fri, 15 Dec 2000 00:28:21 -0800
Received: from framkom.se (lisa.sisu.se [192.36.136.22]) by mail.framkom.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id YNSA8LF5; Fri, 15 Dec 2000 09:30:09 +0100
Message-ID: <3A39D622.60D53243@framkom.se>
Date:   Fri, 15 Dec 2000 09:28:18 +0100
From:   Magnus Fant <magnus@framkom.se>
Organization: FRAMKOM
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.18pre15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: igmp_max_memberships
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi!

Is there a reason igmp_max_memberships is set as low as 20
by default, and what is the best/easiest way to change it
after a reboot? I'm thinking about adding a line to rc.sysinit
(echo 60 > /proc/sys/net/ipv4/igmp_max_memberships), but perhaps
there are issues I don't know?

Greetings, 
Magnus

From owner-netdev@oss.sgi.com Fri Dec 15 04:42:01 2000
Received:  by oss.sgi.com id <S553738AbQLOMlw>;
	Fri, 15 Dec 2000 04:41:52 -0800
Received: from xerxes.thphy.uni-duesseldorf.de ([134.99.64.10]:9388 "EHLO
        xerxes.thphy.uni-duesseldorf.de") by oss.sgi.com with ESMTP
	id <S553711AbQLOMlf>; Fri, 15 Dec 2000 04:41:35 -0800
Received: from chaos.thphy.uni-duesseldorf.de (IDENT:root@chaos [134.99.64.99])
	by xerxes.thphy.uni-duesseldorf.de (8.9.3/8.9.3) with ESMTP id NAA00611
	for <netdev@oss.sgi.com>; Fri, 15 Dec 2000 13:41:31 +0100 (MET)
Received: from localhost (kai@localhost)
	by chaos.thphy.uni-duesseldorf.de (8.9.3/8.8.7) with ESMTP id NAA32649
	for <netdev@oss.sgi.com>; Fri, 15 Dec 2000 13:41:32 +0100
X-Authentication-Warning: chaos.thphy.uni-duesseldorf.de: kai owned process doing -bs
Date:   Fri, 15 Dec 2000 13:41:32 +0100 (CET)
From:   Kai Germaschewski <kai@thphy.uni-duesseldorf.de>
To:     netdev@oss.sgi.com
Subject: alignment issues on netif_rx
Message-ID: <Pine.LNX.4.10.10012151332190.32035-100000@chaos.thphy.uni-duesseldorf.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Some people are planning to use the ISDN code in the linux kernel on their
MIPS port.

They ran into some problems with alignment, and use the following patch to
fix their problems.


diff -ur isdn-HEAD/drivers/isdn/isdn_ppp.c isdn-h/drivers/isdn/isdn_ppp.c
--- isdn-HEAD/drivers/isdn/isdn_ppp.c	Tue Nov 28 15:36:36 2000
+++ isdn-h/drivers/isdn/isdn_ppp.c	Fri Dec 15 11:51:38 2000
@@ -984,8 +984,32 @@
 {
 	struct net_device *dev = &net_dev->dev;
  	struct ippp_struct *is, *mis;
+	
+	struct sk_buff *realign_skb;
+
 	int slot;
 
+	/* Re-align skb data to four-byte alignment if nessecary
+         * Stephen Aaskov, EICON Networks dec. 2000
+	*/
+	if ((int) (skb->data) & 3) {
+	  if( (realign_skb = dev_alloc_skb(skb->len)) == NULL ) {
+	    printk(KERN_ERR "isdn_mppp: cannot allocate sk buff "
+		   "of size %d\n", skb->len);
+	    kfree_skb(skb);
+	    return;
+	  } 
+	  skb_put (realign_skb,skb->len);
+	  memcpy(realign_skb->data, skb->data, skb->len);	  
+	  kfree_skb(skb);
+	  skb = realign_skb;
+	  printk (KERN_INFO "skb re-aligned\n");
+	}
+	
+	/*
+	 * Data is now correct aligned	 
+	*/
+	
 	slot = lp->ppp_slot;
 	if (slot < 0 || slot > ISDN_MAX_CHANNELS) {
 		printk(KERN_ERR "isdn_ppp_push_higher: lp->ppp_slot %d\n", lp->ppp_slot);

At this point we basically do (for proto = PPP_IP)

        skb->protocol = htons(ETH_P_IP);
	skb->dev = dev;
	skb->mac.raw = skb->data;
	netif_rx(skb);

(BTW: Can someone explain what the mac.raw thing is for w.r.t PPP?)

Without the above fix of aligning skb->data on a 4-byte boundary, the
packet would get dropped later on.

Question is: Is this the right way to handle this problem, or should
netif_rx be smarter and take unalignment skbs?
BTW: Would the above realigning make sense on other archs, too
(for performance reasons)?

--Kai




From owner-netdev@oss.sgi.com Fri Dec 15 05:10:01 2000
Received:  by oss.sgi.com id <S553747AbQLONJm>;
	Fri, 15 Dec 2000 05:09:42 -0800
Received: from xerxes.thphy.uni-duesseldorf.de ([134.99.64.10]:22956 "EHLO
        xerxes.thphy.uni-duesseldorf.de") by oss.sgi.com with ESMTP
	id <S553726AbQLONJi>; Fri, 15 Dec 2000 05:09:38 -0800
Received: from chaos.thphy.uni-duesseldorf.de (IDENT:root@chaos [134.99.64.99])
	by xerxes.thphy.uni-duesseldorf.de (8.9.3/8.9.3) with ESMTP id OAA00743
	for <netdev@oss.sgi.com>; Fri, 15 Dec 2000 14:09:35 +0100 (MET)
Received: from localhost (kai@localhost)
	by chaos.thphy.uni-duesseldorf.de (8.9.3/8.8.7) with ESMTP id OAA00315
	for <netdev@oss.sgi.com>; Fri, 15 Dec 2000 14:09:35 +0100
X-Authentication-Warning: chaos.thphy.uni-duesseldorf.de: kai owned process doing -bs
Date:   Fri, 15 Dec 2000 14:09:35 +0100 (CET)
From:   Kai Germaschewski <kai@thphy.uni-duesseldorf.de>
To:     netdev@oss.sgi.com
Subject: Re: alignment issues on netif_rx
In-Reply-To: <Pine.LNX.4.10.10012151332190.32035-100000@chaos.thphy.uni-duesseldorf.de>
Message-ID: <Pine.LNX.4.10.10012151409020.32035-100000@chaos.thphy.uni-duesseldorf.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing



On Fri, 15 Dec 2000, Kai Germaschewski wrote:

> Some people are planning to use the ISDN code in the linux kernel on their
> MIPS port.

Suppose I should have mentioned that the port is based on 2.2.16.

--Kai


From owner-netdev@oss.sgi.com Fri Dec 15 08:10:53 2000
Received:  by oss.sgi.com id <S553772AbQLOQKn>;
	Fri, 15 Dec 2000 08:10:43 -0800
Received: from laurin.munich.netsurf.de ([194.64.166.1]:47285 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S553759AbQLOQK3>; Fri, 15 Dec 2000 08:10:29 -0800
Received: from fred.muc.de (noidentity@ns1247.munich.netsurf.de [195.180.235.247])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id RAA29547;
	Fri, 15 Dec 2000 17:10:27 +0100 (MET)
Received: by fred.muc.de (Postfix, from userid 500)
	id 0A595E3913; Fri, 15 Dec 2000 17:15:47 +0100 (CET)
Date:   Fri, 15 Dec 2000 17:15:47 +0100
From:   Andi Kleen <ak@muc.de>
To:     Kai Germaschewski <kai@thphy.uni-duesseldorf.de>
Cc:     netdev@oss.sgi.com
Subject: Re: alignment issues on netif_rx
Message-ID: <20001215171546.A1033@fred.local>
References: <Pine.LNX.4.10.10012151332190.32035-100000@chaos.thphy. uni-duesseldorf.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.LNX.4.10.10012151332190.32035-100000@chaos.thphy. uni-duesseldorf.de>; from kai@thphy.uni-duesseldorf.de on Fri, Dec 15, 2000 at 01:43:21PM +0100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, Dec 15, 2000 at 01:43:21PM +0100, Kai Germaschewski wrote:
> 
> Some people are planning to use the ISDN code in the linux kernel on their
> MIPS port.
> 
> They ran into some problems with alignment, and use the following patch to
> fix their problems.

Aligning data is the driver's responsibility.

The kernel should not fail though even when it is misaligned, only be slow
because of misalignment traps. This is needed because the driver can not 
always predict for all cases (e.g. EthernetII and 802.3 require different
alignment to get aligned TCP/IP), so it should optimize for the common
case. 

(if that is not true on mips then it is a mips bug) 

-Andi


From owner-netdev@oss.sgi.com Fri Dec 15 08:23:13 2000
Received:  by oss.sgi.com id <S553790AbQLOQWx>;
	Fri, 15 Dec 2000 08:22:53 -0800
Received: from pizda.ninka.net ([216.101.162.242]:4488 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S553780AbQLOQWo>;
	Fri, 15 Dec 2000 08:22:44 -0800
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id IAA20579;
	Fri, 15 Dec 2000 08:06:21 -0800
Date:   Fri, 15 Dec 2000 08:06:21 -0800
Message-Id: <200012151606.IAA20579@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     kai@thphy.uni-duesseldorf.de
CC:     netdev@oss.sgi.com
In-reply-to: 
	<Pine.LNX.4.10.10012151332190.32035-100000@chaos.thphy.uni-duesseldorf.de>
	(message from Kai Germaschewski on Fri, 15 Dec 2000 13:41:32 +0100
	(CET))
Subject: Re: alignment issues on netif_rx
References:  <Pine.LNX.4.10.10012151332190.32035-100000@chaos.thphy.uni-duesseldorf.de>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date:   Fri, 15 Dec 2000 13:41:32 +0100 (CET)
   From: Kai Germaschewski <kai@thphy.uni-duesseldorf.de>

   Without the above fix of aligning skb->data on a 4-byte boundary, the
   packet would get dropped later on.

   Question is: Is this the right way to handle this problem, or should
   netif_rx be smarter and take unalignment skbs?
   BTW: Would the above realigning make sense on other archs, too
   (for performance reasons)?

No, the MIPS port must handle unaligned memory accesses traps
in kernel mode and fix them up.  Every port is required to
do this, these can happen anywhere in the networking.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Sat Dec 16 10:05:07 2000
Received:  by oss.sgi.com id <S553875AbQLPSEq>;
	Sat, 16 Dec 2000 10:04:46 -0800
Received: from wn42-146.sdc.org ([209.155.42.146]:54255 "EHLO lappi")
	by oss.sgi.com with ESMTP id <S553876AbQLPSEc>;
	Sat, 16 Dec 2000 10:04:32 -0800
Received: (ralf@lappi) by bacchus.dhis.org id <S870682AbQLPLvq>;
	Sat, 16 Dec 2000 04:51:46 -0700
Date:	Sat, 16 Dec 2000 12:51:46 +0100
From:	Ralf Baechle <ralf@oss.sgi.com>
To:	"David S. Miller" <davem@redhat.com>
Cc:	kai@thphy.uni-duesseldorf.de, netdev@oss.sgi.com
Subject: Re: alignment issues on netif_rx
Message-ID: <20001216125146.D6896@bacchus.dhis.org>
References: <Pine.LNX.4.10.10012151332190.32035-100000@chaos.thphy.uni-duesseldorf.de> <200012151606.IAA20579@pizda.ninka.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200012151606.IAA20579@pizda.ninka.net>; from davem@redhat.com on Fri, Dec 15, 2000 at 08:06:21AM -0800
X-Accept-Language: de,en,fr
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, Dec 15, 2000 at 08:06:21AM -0800, David S. Miller wrote:

>    Question is: Is this the right way to handle this problem, or should
>    netif_rx be smarter and take unalignment skbs?
>    BTW: Would the above realigning make sense on other archs, too
>    (for performance reasons)?
> 
> No, the MIPS port must handle unaligned memory accesses traps
> in kernel mode and fix them up.  Every port is required to
> do this, these can happen anywhere in the networking.

We do handle them on MIPS - since ca. '95 or so ...

  Ralf

From owner-netdev@oss.sgi.com Sat Dec 16 10:51:56 2000
Received:  by oss.sgi.com id <S553881AbQLPSvr>;
	Sat, 16 Dec 2000 10:51:47 -0800
Received: from quattro.sventech.com ([205.252.248.110]:43270 "HELO
        quattro.sventech.com") by oss.sgi.com with SMTP id <S553879AbQLPSv0>;
	Sat, 16 Dec 2000 10:51:26 -0800
Received: (qmail 9697 invoked by uid 500); 16 Dec 2000 18:51:25 -0000
Date:   Sat, 16 Dec 2000 13:51:25 -0500
From:   Johannes Erdfelt <johannes@erdfelt.com>
To:     "David S. Miller" <davem@redhat.com>
Cc:     kai@thphy.uni-duesseldorf.de, netdev@oss.sgi.com
Subject: Re: alignment issues on netif_rx
Message-ID: <20001216135124.A1045@sventech.com>
References: <Pine.LNX.4.10.10012151332190.32035-100000@chaos.thphy.uni-duesseldorf.de> <200012151606.IAA20579@pizda.ninka.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4i
In-Reply-To: <200012151606.IAA20579@pizda.ninka.net>; from David S. Miller on Fri, Dec 15, 2000 at 08:06:21AM -0800
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, Dec 15, 2000, David S. Miller <davem@redhat.com> wrote:
>    Date:   Fri, 15 Dec 2000 13:41:32 +0100 (CET)
>    From: Kai Germaschewski <kai@thphy.uni-duesseldorf.de>
> 
>    Without the above fix of aligning skb->data on a 4-byte boundary, the
>    packet would get dropped later on.
> 
>    Question is: Is this the right way to handle this problem, or should
>    netif_rx be smarter and take unalignment skbs?
>    BTW: Would the above realigning make sense on other archs, too
>    (for performance reasons)?
> 
> No, the MIPS port must handle unaligned memory accesses traps
> in kernel mode and fix them up.  Every port is required to
> do this, these can happen anywhere in the networking.

The ia64 port cannot handle unaligned memory accesses in kernel mode:

arch/ia64/kernel/unaligned.c:

        /*
         * Unaligned references in the kernel could come from unaligned
         *   arguments to system calls.  We fault the user process in
         *   these cases and panic the kernel otherwise (the kernel should
         *   be fixed to not make unaligned accesses).
         */

[...]

                die_if_kernel("Unaligned reference while in kernel\n",
regs, 30)

However, I can't imagine we've made it this long without this being a
problem so there must be something I'm missing.

JE


From owner-netdev@oss.sgi.com Sun Dec 17 07:14:12 2000
Received:  by oss.sgi.com id <S553926AbQLQPOD>;
	Sun, 17 Dec 2000 07:14:03 -0800
Received: from d-dialin-2364.addcom.de ([62.96.168.212]:24559 "EHLO
        localhost.localdomain") by oss.sgi.com with ESMTP
	id <S553923AbQLQPNj>; Sun, 17 Dec 2000 07:13:39 -0800
Received: from localhost (kai@localhost)
	by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eBHEUji01135;
	Sun, 17 Dec 2000 15:30:45 +0100
X-Authentication-Warning: localhost.localdomain: kai owned process doing -bs
Date:   Sun, 17 Dec 2000 15:30:45 +0100 (CET)
From:   Kai Germaschewski <kai@thphy.uni-duesseldorf.de>
X-Sender:  <kai@vaio>
To:     Ralf Baechle <ralf@oss.sgi.com>
cc:     "David S. Miller" <davem@redhat.com>, <netdev@oss.sgi.com>
Subject: Re: alignment issues on netif_rx
In-Reply-To: <20001216125146.D6896@bacchus.dhis.org>
Message-ID: <Pine.LNX.4.30.0012171528120.1109-100000@vaio>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sat, 16 Dec 2000, Ralf Baechle wrote:

> On Fri, Dec 15, 2000 at 08:06:21AM -0800, David S. Miller wrote:
>
> > No, the MIPS port must handle unaligned memory accesses traps
> > in kernel mode and fix them up.  Every port is required to
> > do this, these can happen anywhere in the networking.
>
> We do handle them on MIPS - since ca. '95 or so ...

I think they're doing their own port to some special hardware - anyway, I
take it they have to fix it to handle the unaligned accesses.

Thanks to everyone.

--Kai



From owner-netdev@oss.sgi.com Sun Dec 17 14:04:02 2000
Received:  by oss.sgi.com id <S553797AbQLQWDn>;
	Sun, 17 Dec 2000 14:03:43 -0800
Received: from laurin.munich.netsurf.de ([194.64.166.1]:13535 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S553705AbQLQWDO>; Sun, 17 Dec 2000 14:03:14 -0800
Received: from fred.muc.de (noidentity@ns1231.munich.netsurf.de [195.180.235.231])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id XAA22766;
	Sun, 17 Dec 2000 23:03:02 +0100 (MET)
Received: by fred.muc.de (Postfix, from userid 500)
	id 0A279E3914; Sun, 17 Dec 2000 22:36:13 +0100 (CET)
Date:   Sun, 17 Dec 2000 22:36:12 +0100
From:   Andi Kleen <ak@muc.de>
To:     Johannes Erdfelt <johannes@erdfelt.com>
Cc:     "David S. Miller" <davem@redhat.com>, kai@thphy.uni-duesseldorf.de,
        netdev@oss.sgi.com
Subject: Re: alignment issues on netif_rx
Message-ID: <20001217223612.A985@fred.local>
References: <Pine.LNX.4.10.10012151332190.32035-100000@chaos.thphy.uni-duesseldorf.de> <200012151606.IAA20579@pizda.ninka.net> <20001216135124.A1045@sventech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20001216135124.A1045@sventech.com>; from johannes@erdfelt.com on Sun, Dec 17, 2000 at 04:21:14PM +0100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sun, Dec 17, 2000 at 04:21:14PM +0100, Johannes Erdfelt wrote:
> 
> However, I can't imagine we've made it this long without this being a
> problem so there must be something I'm missing.

Nobody apparently tried to use IPX on IA64 yet (due to a different ethernet
header length it usually has to deal with an misaligned header)

With this there are also plenty of ways to crash an IA64 box remotely,
e.g. by putting misaligned timestamps into options. 


-Andi

From owner-netdev@oss.sgi.com Sun Dec 17 21:43:24 2000
Received:  by oss.sgi.com id <S553810AbQLRFnO>;
	Sun, 17 Dec 2000 21:43:14 -0800
Received: from pizda.ninka.net ([216.101.162.242]:41114 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S553798AbQLRFm4>;
	Sun, 17 Dec 2000 21:42:56 -0800
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id VAA02308;
	Sun, 17 Dec 2000 21:26:05 -0800
Date:   Sun, 17 Dec 2000 21:26:05 -0800
Message-Id: <200012180526.VAA02308@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     johannes@erdfelt.com
CC:     kai@thphy.uni-duesseldorf.de, netdev@oss.sgi.com
In-reply-to: <20001216135124.A1045@sventech.com> (message from Johannes
	Erdfelt on Sat, 16 Dec 2000 13:51:25 -0500)
Subject: Re: alignment issues on netif_rx
References: <Pine.LNX.4.10.10012151332190.32035-100000@chaos.thphy.uni-duesseldorf.de> <200012151606.IAA20579@pizda.ninka.net> <20001216135124.A1045@sventech.com>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date: Sat, 16 Dec 2000 13:51:25 -0500
   From: Johannes Erdfelt <johannes@erdfelt.com>

   However, I can't imagine we've made it this long without this being
   a problem so there must be something I'm missing.

It only happens when you use non-{ipv4,ipv6} protocols or devices
which do not send aligned packets up to the protocol stack.

Ie. if all you are doing is ethernet + ipv4, you'll never trigger
this.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Sun Dec 17 22:11:23 2000
Received:  by oss.sgi.com id <S553811AbQLRGLO>;
	Sun, 17 Dec 2000 22:11:14 -0800
Received: from linuxcare.com.au ([203.29.91.49]:30983 "EHLO
        front.linuxcare.com.au") by oss.sgi.com with ESMTP
	id <S553805AbQLRGK5>; Sun, 17 Dec 2000 22:10:57 -0800
Received: from halfway (localhost [127.0.0.1])
	by front.linuxcare.com.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id RAA17078;
	Mon, 18 Dec 2000 17:10:35 +1100
X-Authentication-Warning: front.linuxcare.com.au: Host localhost [127.0.0.1] claimed to be halfway
Received: from halfway
	([127.0.0.1] helo=linuxcare.com.au ident=rusty)
	by halfway with esmtp (Exim 3.20 #1 (Debian))
	id 147tVK-0006aC-00; Mon, 18 Dec 2000 17:10:34 +1100
From:   Rusty Russell <rusty@linuxcare.com.au>
To:     netdev@oss.sgi.com, netfilter@us5.samba.org
cc:     Xuan Baldauf <xuan--netfilter-devel@baldauf.org>
Subject: [PATCH] early conntrack ref release.
Date:   Mon, 18 Dec 2000 17:10:34 +1100
Message-Id: <E147tVK-0006aC-00@halfway>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Trivial patch from Xuan, which frees conntrack early.

Rusty.
--
Hacking time.
diff -urN -I \$.*\$ -X /tmp/kerndiff.RnRDbE --minimal linux-2.4.0-test13-3/net/ipv4/ip_input.c working-2.4.0-test13-3/net/ipv4/ip_input.c
--- linux-2.4.0-test13-3/net/ipv4/ip_input.c	Tue Dec 12 14:28:06 2000
+++ working-2.4.0-test13-3/net/ipv4/ip_input.c	Mon Dec 18 17:07:06 2000
@@ -225,6 +225,13 @@
 	nf_debug_ip_local_deliver(skb);
 #endif /*CONFIG_NETFILTER_DEBUG*/
 
+#ifdef CONFIG_NETFILTER
+	/* Free reference early: we don't need it any more, and it may
+           hold ip_conntrack module loaded indefinitely. */
+	nf_conntrack_put(skb->nfct);
+	skb->nfct = NULL;
+#endif /*CONFIG_NETFILTER*/
+
         /* Point into the IP datagram, just past the header. */
         skb->h.raw = skb->nh.raw + iph->ihl*4;
 

From owner-netdev@oss.sgi.com Sun Dec 17 23:57:44 2000
Received:  by oss.sgi.com id <S553819AbQLRH5Z>;
	Sun, 17 Dec 2000 23:57:25 -0800
Received: from pop3.web.de ([212.227.116.81]:48393 "HELO smtp.web.de")
	by oss.sgi.com with SMTP id <S553812AbQLRH44>;
	Sun, 17 Dec 2000 23:56:56 -0800
Received: from ganerc by smtp.web.de with smtp
	(freemail 4.2.1.0 #3) id m147vA8-005CGTC; Mon, 18 Dec 2000 08:56 +0100
From:   "Michael Illgner" <fillg1@web.de>
To:     <andrewm@uow.edu.au>
Cc:     <netdev@oss.sgi.com>, <linux-kernel@vger.kernel.org>
Subject: Problem with 3c59x and 3C905B
Date:   Mon, 18 Dec 2000 08:55:27 +0100
Message-ID: <JDEJLKPAIGJAKBJPIALIIEKOCBAA.fillg1@web.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi folks,
I have some trouble using a 3COM NIC905B and the 3c59x driver with kernel
2.2.x
and 2.4.0.testx. First of all the card works fine with Windows or with linux
2.2.18
using the 3c90x driver supplied by 3COM. But with the 3c59x driver I get
transfer rates
below 10k/s or even lower. The card is connected to a 10/100 Hub (Netgear
DS104).

Here are some informations

Kernel version

2.2.18 SMP and 2.4.0.test12 SMP (latest kernel) but the problem seems
to be independent of the kernel version.


Banner message

Dec 17 19:44:48 ganerc kernel: 3c59x.c:LK1.1.11 13 Nov 2000  Donald Becker
and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $
Dec 17 19:44:48 ganerc kernel: See Documentation/networking/vortex.txt
Dec 17 19:44:48 ganerc kernel: eth0: 3Com PCI 3c905B Cyclone 100baseTx at
0xdc00,  00:10:5a:d8:25:f1, IRQ 19
Dec 17 19:44:48 ganerc kernel: Full duplex capable
Dec 17 19:44:48 ganerc kernel:   8K byte-wide RAM 5:3 Rx:Tx split,
autoselect/Autonegotiate interface.
Dec 17 19:44:48 ganerc kernel:   MII transceiver found at address 24, status
786d.
Dec 17 19:44:48 ganerc kernel:   MII transceiver found at address 0, status
786d.
Dec 17 19:44:48 ganerc kernel:   Enabling bus-master transmits and
whole-frame receives.
Dec 17 19:44:48 ganerc kernel: eth0: using NWAY autonegotiation


lspci -vx

00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
(rev 30)
	Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
	Flags: bus master, medium devsel, latency 64, IRQ 19
	I/O ports at dc00 [size=128]
	Memory at e1000000 (32-bit, non-prefetchable) [size=128]
	Expansion ROM at df000000 [disabled] [size=128K]
	Capabilities: [dc] Power Management version 1
00: b7 10 55 90 07 00 10 02 30 00 00 02 08 40 00 00
10: 01 dc 00 00 00 00 00 e1 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 55 90
30: 00 00 00 df dc 00 00 00 00 00 00 00 0a 01 0a 0a


Here are some messages from syslog

Dec 17 19:59:15 ganerc kernel: vortex_up(): writing 0x3800000 to
InternalConfig
Dec 17 19:59:15 ganerc kernel: eth0: MII #24 status 786d, link partner
capability 40a1, setting half-duplex.
Dec 17 19:59:15 ganerc kernel: eth0: MII #24 status 786d, link partner
capability 40a1, setting half-duplex.
Dec 17 19:59:15 ganerc kernel: eth0: vortex_up() InternalConfig 03800000.
Dec 17 19:59:15 ganerc kernel: eth0: vortex_up() irq 19 media status 8080.
Dez 17 19:59:16 ganerc network: Bringing up interface eth0:  succeeded
Dec 17 19:59:18 ganerc kernel: eth0: Media selection timer tick happened,
Autonegotiate.
Dec 17 19:59:18 ganerc kernel: dev->watchdog_timeo=40
Dec 17 19:59:18 ganerc kernel: eth0: MII transceiver has status 7869.
Dec 17 19:59:18 ganerc kernel: eth0: Media selection timer finished,
Autonegotiate.
Dec 17 19:59:29 ganerc kernel: boomerang_start_xmit()
Dec 17 19:59:29 ganerc kernel: eth0: Trying to send a packet, Tx index 0.
Dec 17 19:59:29 ganerc kernel: boomerang_interrupt. status=0xe201
Dec 17 19:59:29 ganerc kernel: eth0: interrupt, status e201, latency 8
ticks.
Dec 17 19:59:29 ganerc kernel: eth0: In interrupt loop, status e201.
Dec 17 19:59:29 ganerc kernel: eth0: exiting interrupt, status e000.
Dec 17 19:59:29 ganerc kernel: boomerang_interrupt. status=0xe401
Dec 17 19:59:29 ganerc kernel: eth0: interrupt, status e401, latency 6
ticks.
Dec 17 19:59:29 ganerc kernel: eth0: In interrupt loop, status e401.
Dec 17 19:59:29 ganerc kernel: boomerang_interrupt->boomerang_rx
Dec 17 19:59:29 ganerc kernel: boomerang_rx(): status e001
Dec 17 19:59:29 ganerc kernel: Receiving packet size 60 status 803c.
Dec 17 19:59:29 ganerc kernel: eth0: exiting interrupt, status e000.
Dec 17 19:59:29 ganerc kernel: boomerang_start_xmit()
Dec 17 19:59:29 ganerc kernel: eth0: Trying to send a packet, Tx index 1.
Dec 17 19:59:29 ganerc kernel: boomerang_interrupt. status=0xe201
Dec 17 19:59:29 ganerc kernel: eth0: interrupt, status e201, latency 5
ticks.
Dec 17 19:59:29 ganerc kernel: eth0: In interrupt loop, status e201.
Dec 17 19:59:29 ganerc kernel: eth0: exiting interrupt, status e000.
Dec 17 19:59:29 ganerc kernel: boomerang_interrupt. status=0xe401
Dec 17 19:59:29 ganerc kernel: eth0: interrupt, status e401, latency 6
ticks.
Dec 17 19:59:29 ganerc kernel: eth0: In interrupt loop, status e401.
Dec 17 19:59:29 ganerc kernel: boomerang_interrupt->boomerang_rx
Dec 17 19:59:29 ganerc kernel: boomerang_rx(): status e001
Dec 17 19:59:29 ganerc kernel: Receiving packet size 98 status 20008062.
Dec 17 19:59:29 ganerc kernel: eth0: exiting interrupt, status e000.
Dec 17 19:59:30 ganerc kernel: boomerang_start_xmit()
Dec 17 19:59:30 ganerc kernel: eth0: Trying to send a packet, Tx index 2.
Dec 17 19:59:30 ganerc kernel: boomerang_interrupt. status=0xe201
Dec 17 19:59:30 ganerc kernel: eth0: interrupt, status e201, latency 5
ticks.
Dec 17 19:59:30 ganerc kernel: eth0: In interrupt loop, status e201.
Dec 17 19:59:30 ganerc kernel: eth0: exiting interrupt, status e000.
Dec 17 19:59:30 ganerc kernel: boomerang_interrupt. status=0xe401
Dec 17 19:59:30 ganerc kernel: eth0: interrupt, status e401, latency 5
ticks.
Dec 17 19:59:30 ganerc kernel: eth0: In interrupt loop, status e401.
Dec 17 19:59:30 ganerc kernel: boomerang_interrupt->boomerang_rx
Dec 17 19:59:30 ganerc kernel: boomerang_rx(): status e001
Dec 17 19:59:30 ganerc kernel: Receiving packet size 98 status 20008062.
Dec 17 19:59:30 ganerc kernel: eth0: exiting interrupt, status e000.
Dec 17 19:59:31 ganerc kernel: boomerang_start_xmit()
Dec 17 19:59:31 ganerc kernel: eth0: Trying to send a packet, Tx index 3.
Dec 17 19:59:31 ganerc kernel: boomerang_interrupt. status=0xe201
Dec 17 19:59:31 ganerc kernel: eth0: interrupt, status e201, latency 4
ticks.
Dec 17 19:59:31 ganerc kernel: eth0: In interrupt loop, status e201.
Dec 17 19:59:31 ganerc kernel: eth0: exiting interrupt, status e000.
Dec 17 19:59:31 ganerc kernel: boomerang_interrupt. status=0xe401
Dec 17 19:59:31 ganerc kernel: eth0: interrupt, status e401, latency 5
ticks.
Dec 17 19:59:31 ganerc kernel: eth0: In interrupt loop, status e401.
Dec 17 19:59:31 ganerc kernel: boomerang_interrupt->boomerang_rx


the ouput from vortex-diag -aaee is

vortex-diag.c:v2.03 9/26/2000 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Index #1: Found a 3c905B Cyclone 100baseTx adapter at 0xdc00.
The Vortex chip may be active, so FIFO registers will not be read.
To see all register values use the '-f' flag.
Initial window 7, registers values by window:
  Window 0: 0000 0000 0000 0000 0000 00bf 0000 0000.
  Window 1: FIFO FIFO 0000 0000 0000 0000 0000 2000.
  Window 2: 1000 d85a f125 0000 0000 0000 000a 4000.
  Window 3: 0000 0380 05ea 0020 000a 0800 0800 6000.
  Window 4: 0000 0000 0000 0cd8 0003 8880 0000 8000.
  Window 5: 1ffc 0000 0000 0600 0805 06ce 06c6 a000.
  Window 6: 0000 0000 0000 4a01 0100 3c43 6176 c000.
  Window 7: 0000 0000 0000 0000 0000 0000 0000 e000.
Vortex chip registers at 0xdc00
  0xDC10: **FIFO** 00000000 0000000d *STATUS*
  0xDC20: 00000020 00000000 00080000 00000004
  0xDC30: 00000000 bea6415a 0c05e060 00080004
 Indication enable is 06c6, interrupt enable is 06ce.
 No interrupt sources are pending.
 Transceiver/media interfaces available:  100baseTx 10baseT.
Transceiver type in use:  Autonegotiate.
 MAC settings: full-duplex.
 Station address set to 00:10:5a:d8:25:f1.
 Configuration options 000a.
EEPROM contents (64 words, offset 0):
 0x000: 0010 5ad8 25f1 9055 c579 0036 5051 6d50
 0x008: 2971 0000 0010 5ad8 25f1 8010 0000 0022
 0x010: 32a2 0000 0000 0380 0000 0004 0000 10b7
 0x018: 9055 000a 0000 0000 0000 0000 0000 0000
 0x020: 00e6 0000 0000 0000 0000 0000 0000 0000
 0x028: 0000 0000 0000 0000 0000 0000 0000 0000
 0x030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x038: 0000 0000 0000 0000 0000 0000 0000 0000
 The word-wide EEPROM checksum is 0x971c.
Parsing the EEPROM of a 3Com Vortex/Boomerang:
 3Com Node Address 00:10:5A:D8:25:F1 (used as a unique ID only).
 OEM Station address 00:10:5A:D8:25:F1 (used as the ethernet address).
 Manufacture date (MM/DD/YYYY) 11/25/1998, division 6, product QP.
Options: force full-duplex.
  Vortex format checksum is incorrect (008e vs. 10b7).
  Cyclone format checksum is correct (0xe6 vs. 0xe6).
  Hurricane format checksum is correct (0xe6 vs. 0xe6).


output from mii-diag -v

mii-diag.c:v2.00 4/19/2000  Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
 MII PHY #24 transceiver registers:
   3000 786d 0000 0000 01e1 40a1 0007 2801
   0000 0000 0000 0000 0000 0000 0000 0000
   8000 0afb f5ff 0000 0000 0005 2001 0000
   0000 2042 0044 1c11 0012 1000 0000 0000.
 Basic mode control register 0x3000: Auto-negotiation enabled.
 You have link beat, and everything is working OK.
   This transceiver is capable of  100baseTx-FD 100baseTx 10baseT-FD
10baseT.
   Able to perform Auto-negotiation, negotiation complete.
 Your link partner advertised 40a1: 100baseTx 10baseT.
 MII PHY #24 transceiver registers:
   3000 786d 0000 0000 01e1 40a1 0005 2801
   0000 0000 0000 0000 0000 0000 0000 0000
   8000 0008 0090 0000 0000 0005 2001 0000
   0000 2042 0044 1c11 0002 1000 0000 0000.
 Basic mode control register 0x3000: Auto-negotiation enabled.
 Basic mode status register 0x786d ... 786d.
   Link status: established.
   Capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.
   Able to perform Auto-negotiation, negotiation complete.
 This transceiver has no vendor identification.
 I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT
   Advertising no additional info pages.
   IEEE 802.3 CSMA/CD protocol.
 Link partner capability is 40a1: 100baseTx 10baseT.
   Negotiation  completed.

Any idea what is going wrong here ?


Thanks in advance for your help...


Michael Illgner


From owner-netdev@oss.sgi.com Mon Dec 18 02:02:05 2000
Received:  by oss.sgi.com id <S553835AbQLRKBz>;
	Mon, 18 Dec 2000 02:01:55 -0800
Received: from isis.its.uow.edu.au ([130.130.68.21]:10477 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S553827AbQLRKBh>;
	Mon, 18 Dec 2000 02:01:37 -0800
Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12])
	by isis.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id VAA21826;
	Mon, 18 Dec 2000 21:01:12 +1100 (EST)
Message-ID: <3A3DE163.5AC30492@uow.edu.au>
Date:   Mon, 18 Dec 2000 21:05:23 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Michael Illgner <fillg1@web.de>
CC:     netdev@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: Problem with 3c59x and 3C905B
References: <JDEJLKPAIGJAKBJPIALIIEKOCBAA.fillg1@web.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Michael Illgner wrote:
> 
> Hi folks,

Hello, Michael.  Good problem report.  You've done this before.

> ...
> Dec 17 19:44:48 ganerc kernel: Full duplex capable

Uh-oh.  Someone has set the `full duplex' bit in your
EEPROM.  Bit 15, word 0x0d.

>...
> Dec 17 19:59:15 ganerc kernel: eth0: MII #24 status 786d, link partner
> capability 40a1

40a1: the link partner is advertising only 10/100 half duplex.

> , setting half-duplex.

heh.  The driver lies.

> ...
>  MAC settings: full-duplex.

But vortex-diag doesn't.  You're running full-duplex.

> ...
> EEPROM contents (64 words, offset 0):
>  0x000: 0010 5ad8 25f1 9055 c579 0036 5051 6d50
>  0x008: 2971 0000 0010 5ad8 25f1 8010 0000 0022
                                   ^
                                  ^^^
> ...
> Options: force full-duplex.

And here is why - it's that EEPROM bit.

> ...
> Any idea what is going wrong here ?

You need to clear that bit - then the driver will run half-duplex.
If you have the 3com DOS-based config tool you can probably do
it with that.  Alternatively, see if you can get vortex-diag
(http://www.scyld.com/diag/) to do it - I find vortex-diag's
EEPROM writing a bit tricky to use.  So be careful to save the
output of `vortex-diag -ee' as a backup first.

You can probably kludge it in the driver with:

    /* Extract our information from the EEPROM data. */
    vp->info1 = eeprom[13];
+   vp->info1 &= ~0x8000;
    vp->info2 = eeprom[15];


Working out why your switch isn't talking full-duplex would
probably make things work too, but it's not a fix.

-

From owner-netdev@oss.sgi.com Mon Dec 18 07:32:07 2000
Received:  by oss.sgi.com id <S553850AbQLRPbr>;
	Mon, 18 Dec 2000 07:31:47 -0800
Received: from smtp1.cern.ch ([137.138.128.38]:44303 "EHLO smtp1.cern.ch")
	by oss.sgi.com with ESMTP id <S553815AbQLRPbm>;
	Mon, 18 Dec 2000 07:31:42 -0800
Received: from lxplus015.cern.ch (IDENT:root@lxplus015.cern.ch [137.138.161.112])
	by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id QAA30366;
	Mon, 18 Dec 2000 16:30:54 +0100 (MET)
Received: (from jes@localhost)
	by lxplus015.cern.ch (8.9.3/8.9.3) id QAA29608;
	Mon, 18 Dec 2000 16:30:52 +0100
To:     Andi Kleen <ak@muc.de>
Cc:     Johannes Erdfelt <johannes@erdfelt.com>,
        "David S. Miller" <davem@redhat.com>, kai@thphy.uni-duesseldorf.de,
        netdev@oss.sgi.com
Subject: Re: alignment issues on netif_rx
References: <Pine.LNX.4.10.10012151332190.32035-100000@chaos.thphy.uni-duesseldorf.de> <200012151606.IAA20579@pizda.ninka.net> <20001216135124.A1045@sventech.com> <20001217223612.A985@fred.local>
From:   Jes Sorensen <jes@linuxcare.com>
Date:   18 Dec 2000 16:30:52 +0100
In-Reply-To: Andi Kleen's message of "Sun, 17 Dec 2000 22:36:12 +0100"
Message-ID: <d34s01vj9v.fsf@lxplus015.cern.ch>
Lines:  24
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "Andi" == Andi Kleen <ak@muc.de> writes:

Andi> On Sun, Dec 17, 2000 at 04:21:14PM +0100, Johannes Erdfelt
Andi> wrote:
>>  However, I can't imagine we've made it this long without this
>> being a problem so there must be something I'm missing.

Andi> Nobody apparently tried to use IPX on IA64 yet (due to a
Andi> different ethernet header length it usually has to deal with an
Andi> misaligned header)

Andi> With this there are also plenty of ways to crash an IA64 box
Andi> remotely, e.g. by putting misaligned timestamps into options.

I have been thinking about adding mis-word-aligned read/write macros
to the networking code for this reason. Ie. less generic macros that
will load half words and merge them instead of the very generic
misaligned load macros. This way architectures that do not have a
problem with misaligned word loads but do have mis aligned byte loads
can optimize it away.

I think some of the Alphas have the alignment problems as well.

Jes

From owner-netdev@oss.sgi.com Mon Dec 18 09:25:18 2000
Received:  by oss.sgi.com id <S553859AbQLRRY5>;
	Mon, 18 Dec 2000 09:24:57 -0800
Received: from host.stormwire.com ([209.239.61.195]:62983 "EHLO
        host.stormwire.com") by oss.sgi.com with ESMTP id <S553855AbQLRRYt>;
	Mon, 18 Dec 2000 09:24:49 -0800
Received: from roo ([64.78.147.215])
	by host.stormwire.com (8.10.2/8.10.2) with SMTP id eBIHOYM16360;
	Mon, 18 Dec 2000 12:24:34 -0500
From:   <jgoins@sunmine.com>
To:     "Andrew Morton" <andrewm@uow.edu.au>
Cc:     <netdev@oss.sgi.com>, <linux-kernel@vger.kernel.org>
Subject: RE: Problem with 3c59x and 3C905B
Date:   Mon, 18 Dec 2000 12:29:23 -0500
Message-ID: <NCBBIGEIEDLIBLJACBEOEEECDGAA.jgoins@sunmine.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3A3DE163.5AC30492@uow.edu.au>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Andrew Morton wrote:
>
> Working out why your switch isn't talking full-duplex would
> probably make things work too, but it's not a fix.
>

He said he has a 10/100 hub (NG DS104) -- it is a half-duplex only 10/100
hub.

Regards,
JGoins
jgoins@sunmine.com


From owner-netdev@oss.sgi.com Mon Dec 18 10:09:28 2000
Received:  by oss.sgi.com id <S553866AbQLRSJS>;
	Mon, 18 Dec 2000 10:09:18 -0800
Received: from mail-out.chello.nl ([213.46.240.7]:28754 "EHLO
        amsmta06-svc.chello.nl") by oss.sgi.com with ESMTP
	id <S553863AbQLRSJF>; Mon, 18 Dec 2000 10:09:05 -0800
Received: from server.serve.me.nl ([213.46.120.26])
          by amsmta06-svc.chello.nl
          (InterMail vK.4.02.00.10 201-232-116-110 license a20ebc008716c6ca05397a05e78c7098)
          with ESMTP
          id <20001218181001.MTPP23899.amsmta06-svc@server.serve.me.nl>;
          Mon, 18 Dec 2000 19:10:01 +0100
Date:   Mon, 18 Dec 2000 20:16:22 +0100 (CET)
From:   Igmar Palsenberg <maillist@chello.nl>
X-Sender: maillist@server.serve.me.nl
To:     Michael Illgner <fillg1@web.de>
cc:     andrewm@uow.edu.au, netdev@oss.sgi.com,
        linux-kernel@vger.kernel.org
Subject: Re: Problem with 3c59x and 3C905B
In-Reply-To: <JDEJLKPAIGJAKBJPIALIIEKOCBAA.fillg1@web.de>
Message-ID: <Pine.LNX.4.21.0012182012210.8296-100000@server.serve.me.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, 18 Dec 2000, Michael Illgner wrote:

> Hi folks,
> I have some trouble using a 3COM NIC905B and the 3c59x driver with kernel
> 2.2.x
> and 2.4.0.testx. First of all the card works fine with Windows or with linux
> 2.2.18
> using the 3c90x driver supplied by 3COM. But with the 3c59x driver I get
> transfer rates

This kernel is a stock 2.2.17 with acl patches (doesn't change anything
network-related).

Bootup msg :

3c59x.c 16Aug00 Donald Becker and others
http://www.scyld.com/network/vortex.html
eth0: 3Com 3c905B Cyclone 100baseTx at 0x6c00,  00:10:5a:68:ea:ad, IRQ 11
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 24, status 786d.
MII transceiver found at address 0, status 786d.
Enabling bus-master transmits and whole-frame receives.

> below 10k/s or even lower. The card is connected to a 10/100 Hub (Netgear
> DS104).

You're sure that hub can handle full-fuplex mode ? Because that's what the
card uses in your case.

> Here are some informations
> 
> Kernel version
> 
> 2.2.18 SMP and 2.4.0.test12 SMP (latest kernel) but the problem seems
> to be independent of the kernel version.
> 
> 
> Banner message
> 
> Dec 17 19:44:48 ganerc kernel: 3c59x.c:LK1.1.11 13 Nov 2000  Donald Becker
> and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $
> Dec 17 19:44:48 ganerc kernel: See Documentation/networking/vortex.txt
> Dec 17 19:44:48 ganerc kernel: eth0: 3Com PCI 3c905B Cyclone 100baseTx at
> 0xdc00,  00:10:5a:d8:25:f1, IRQ 19
> Dec 17 19:44:48 ganerc kernel: Full duplex capable
> Dec 17 19:44:48 ganerc kernel:   8K byte-wide RAM 5:3 Rx:Tx split,
> autoselect/Autonegotiate interface.
> Dec 17 19:44:48 ganerc kernel:   MII transceiver found at address 24, status
> 786d.
> Dec 17 19:44:48 ganerc kernel:   MII transceiver found at address 0, status
> 786d.
> Dec 17 19:44:48 ganerc kernel:   Enabling bus-master transmits and
> whole-frame receives.
> Dec 17 19:44:48 ganerc kernel: eth0: using NWAY autonegotiation

Ik hate everything that has the word 'auto' in it. Usually means problems.

<snip>

I suggest you start at that hub. The fact that you state that is is kernel
independant makes me think it's not a kernel / driver bug, but that your
network chokes on the autoconfig.




	Igmar


From owner-netdev@oss.sgi.com Mon Dec 18 10:21:47 2000
Received:  by oss.sgi.com id <S553860AbQLRSV2>;
	Mon, 18 Dec 2000 10:21:28 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:33810 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553665AbQLRSVE>;
	Mon, 18 Dec 2000 10:21:04 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA31036; Mon, 18 Dec 2000 21:20:14 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012181820.VAA31036@ms2.inr.ac.ru>
Subject: Re: alignment issues on netif_rx
To:     jes@linuxcare.COM (Jes Sorensen)
Date:   Mon, 18 Dec 2000 21:20:14 +0300 (MSK)
Cc:     netdev@oss.sgi.com, davem@redhat.com (Dave Miller)
In-Reply-To: <d34s01vj9v.fsf@lxplus015.cern.ch> from "Jes Sorensen" at Dec 18, 0 06:45:01 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 231       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> I have been thinking about adding mis-word-aligned read/write macros
> to the networking code for this reason.

Header splitting is possible now, by the way.

This looks better then prohibiting to use plain C. 8)

Alexey

From owner-netdev@oss.sgi.com Mon Dec 18 10:37:18 2000
Received:  by oss.sgi.com id <S553865AbQLRShI>;
	Mon, 18 Dec 2000 10:37:08 -0800
Received: from [216.101.162.242] ([216.101.162.242]:35488 "EHLO
        pizda.ninka.net") by oss.sgi.com with ESMTP id <S553752AbQLRSgw>;
	Mon, 18 Dec 2000 10:36:52 -0800
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id KAA05534;
	Mon, 18 Dec 2000 10:14:56 -0800
Date:   Mon, 18 Dec 2000 10:14:56 -0800
Message-Id: <200012181814.KAA05534@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     rusty@linuxcare.com.au
CC:     netdev@oss.sgi.com, netfilter@us5.samba.org,
        xuan--netfilter-devel@baldauf.org
In-reply-to: <E147tVK-0006aC-00@halfway> (message from Rusty Russell on Mon,
	18 Dec 2000 17:10:34 +1100)
Subject: Re: [PATCH] early conntrack ref release.
References:  <E147tVK-0006aC-00@halfway>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   From: Rusty Russell <rusty@linuxcare.com.au>
   Date:   Mon, 18 Dec 2000 17:10:34 +1100

   Trivial patch from Xuan, which frees conntrack early.

Patch applied, thanks.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Mon Dec 18 11:17:30 2000
Received:  by oss.sgi.com id <S553867AbQLRTRU>;
	Mon, 18 Dec 2000 11:17:20 -0800
Received: from smtp1.cern.ch ([137.138.128.38]:14090 "EHLO smtp1.cern.ch")
	by oss.sgi.com with ESMTP id <S553820AbQLRTRF>;
	Mon, 18 Dec 2000 11:17:05 -0800
Received: from lxplus015.cern.ch (IDENT:root@lxplus015.cern.ch [137.138.161.112])
	by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id UAA26341;
	Mon, 18 Dec 2000 20:16:58 +0100 (MET)
Received: (from jes@localhost)
	by lxplus015.cern.ch (8.9.3/8.9.3) id UAA05269;
	Mon, 18 Dec 2000 20:16:58 +0100
To:     kuznet@ms2.inr.ac.ru
Cc:     netdev@oss.sgi.com, davem@redhat.com (Dave Miller)
Subject: Re: alignment issues on netif_rx
References: <200012181820.VAA31036@ms2.inr.ac.ru>
From:   Jes Sorensen <jes@linuxcare.com>
Date:   18 Dec 2000 20:16:58 +0100
In-Reply-To: kuznet@ms2.inr.ac.ru's message of "Mon, 18 Dec 2000 21:20:14 +0300 (MSK)"
Message-ID: <d3zohttu8l.fsf@lxplus015.cern.ch>
Lines:  14
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "ANK" == kuznet  <kuznet@ms2.inr.ac.ru> writes:

ANK> Hello!
>> I have been thinking about adding mis-word-aligned read/write
>> macros to the networking code for this reason.

ANK> Header splitting is possible now, by the way.

ANK> This looks better then prohibiting to use plain C. 8)

The problem is that some cards like the Tulip and Starfire don't allow
misaligned DMA.

Jes

From owner-netdev@oss.sgi.com Mon Dec 18 11:31:20 2000
Received:  by oss.sgi.com id <S553873AbQLRTbK>;
	Mon, 18 Dec 2000 11:31:10 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:13572 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553834AbQLRTaw>;
	Mon, 18 Dec 2000 11:30:52 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA32333; Mon, 18 Dec 2000 22:30:31 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012181930.WAA32333@ms2.inr.ac.ru>
Subject: Re: alignment issues on netif_rx
To:     jes@linuxcare.com (Jes Sorensen)
Date:   Mon, 18 Dec 2000 22:30:31 +0300 (MSK)
Cc:     netdev@oss.sgi.com, davem@redhat.com
In-Reply-To: <d3zohttu8l.fsf@lxplus015.cern.ch> from "Jes Sorensen" at Dec 18, 0 08:16:58 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 317       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> The problem is that some cards like the Tulip and Starfire don't allow
> misaligned DMA.

Aligned dma can be always used and, if protocol happens to be ethernet II,
headers can be copied for faulty architectures. Actually, I am even not sure
that misaligned accesses for intel are better than copy.

Alexey

From owner-netdev@oss.sgi.com Mon Dec 18 12:28:10 2000
Received:  by oss.sgi.com id <S553870AbQLRU2A>;
	Mon, 18 Dec 2000 12:28:00 -0800
Received: from smtp1.cern.ch ([137.138.128.38]:65035 "EHLO smtp1.cern.ch")
	by oss.sgi.com with ESMTP id <S553650AbQLRU1p>;
	Mon, 18 Dec 2000 12:27:45 -0800
Received: from lxplus015.cern.ch (IDENT:root@lxplus015.cern.ch [137.138.161.112])
	by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id VAA09735;
	Mon, 18 Dec 2000 21:27:38 +0100 (MET)
Received: (from jes@localhost)
	by lxplus015.cern.ch (8.9.3/8.9.3) id VAA04210;
	Mon, 18 Dec 2000 21:27:37 +0100
To:     kuznet@ms2.inr.ac.ru
Cc:     netdev@oss.sgi.com, davem@redhat.com
Subject: Re: alignment issues on netif_rx
References: <200012181930.WAA32333@ms2.inr.ac.ru>
From:   Jes Sorensen <jes@linuxcare.com>
Date:   18 Dec 2000 21:27:37 +0100
In-Reply-To: kuznet@ms2.inr.ac.ru's message of "Mon, 18 Dec 2000 22:30:31 +0300 (MSK)"
Message-ID: <d3r935tqyu.fsf@lxplus015.cern.ch>
Lines:  16
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "kuznet" == kuznet  <kuznet@ms2.inr.ac.ru> writes:

kuznet> Hello!
>> The problem is that some cards like the Tulip and Starfire don't
>> allow misaligned DMA.

kuznet> Aligned dma can be always used and, if protocol happens to be
kuznet> ethernet II, headers can be copied for faulty
kuznet> architectures. Actually, I am even not sure that misaligned
kuznet> accesses for intel are better than copy.

This still requires that the card can DMA to multiple buffers, or are
you suggesting to copy out the header no matter what?

Jes


From owner-netdev@oss.sgi.com Mon Dec 18 12:32:41 2000
Received:  by oss.sgi.com id <S553876AbQLRUcU>;
	Mon, 18 Dec 2000 12:32:20 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:56324 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553702AbQLRUcI>;
	Mon, 18 Dec 2000 12:32:08 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA00572; Mon, 18 Dec 2000 23:31:37 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012182031.XAA00572@ms2.inr.ac.ru>
Subject: Re: alignment issues on netif_rx
To:     jes@linuxcare.com (Jes Sorensen)
Date:   Mon, 18 Dec 2000 23:31:37 +0300 (MSK)
Cc:     netdev@oss.sgi.com, davem@redhat.com
In-Reply-To: <d3r935tqyu.fsf@lxplus015.cern.ch> from "Jes Sorensen" at Dec 18, 0 09:27:37 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 310       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> This still requires that the card can DMA to multiple buffers,

If they cannot dma to not aligned buffers, scatter dma is meaningless
in any case.


>						 or are
> you suggesting to copy out the header no matter what?

To copy, of course. These cards do this for small packets in any case.

Alexey

From owner-netdev@oss.sgi.com Mon Dec 18 14:39:21 2000
Received:  by oss.sgi.com id <S553691AbQLRWjL>;
	Mon, 18 Dec 2000 14:39:11 -0800
Received: from kogge.hanse.de ([192.76.134.17]:11280 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S553733AbQLRWi5>;
	Mon, 18 Dec 2000 14:38:57 -0800
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id XAA06727;
	Mon, 18 Dec 2000 23:38:46 +0100 (CET)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id VAA02985;
	Mon, 18 Dec 2000 21:19:50 +0100
To:     "David S. Miller" <davem@redhat.com>
cc:     netdev@oss.sgi.com, johannes@erdfelt.com,
        kai@thphy.uni-duesseldorf.de
Subject: Re: alignment issues on netif_rx
References: <Pine.LNX.4.10.10012151332190.32035-100000@chaos.thphy.uni-duesseldorf.de> <200012151606.IAA20579@pizda.ninka.net> <20001216135124.A1045@sventech.com> <200012180526.VAA02308@pizda.ninka.net>
From:   Henner Eisen <eis@baty.hanse.de>
Date:   18 Dec 2000 21:19:49 +0100
In-Reply-To: "David S. Miller"'s message of "Sun, 17 Dec 2000 21:26:05 -0800"
Message-ID: <ouwvcxxz16.fsf@baty.hanse.de>
Lines:  13
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "David" == David S Miller <davem@redhat.com> writes:

    David> It only happens when you use non-{ipv4,ipv6} protocols or
    David> devices which do not send aligned packets up to the
    David> protocol stack.

    David> Ie. if all you are doing is ethernet + ipv4, you'll never
    David> trigger this.

PPP is in particular affected by this because the length of the header
is not fixed.

Henner

From owner-netdev@oss.sgi.com Mon Dec 18 14:39:31 2000
Received:  by oss.sgi.com id <S553877AbQLRWjV>;
	Mon, 18 Dec 2000 14:39:21 -0800
Received: from kogge.hanse.de ([192.76.134.17]:12048 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S553733AbQLRWjN>;
	Mon, 18 Dec 2000 14:39:13 -0800
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id XAA06733
	for netdev@oss.sgi.com; Mon, 18 Dec 2000 23:39:12 +0100 (CET)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id XAA03137;
	Mon, 18 Dec 2000 23:06:11 +0100
Date:   Mon, 18 Dec 2000 23:06:11 +0100
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200012182206.XAA03137@baty.hanse.de>
To:     netdev@oss.sgi.com
Subject: migrating to lock_sock()
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Hi,

while thinking about how to fully replace the BKL-based by lock_sock()-based
socket locking inside the AF_X25 stack, I encountered some questions:

The X.25 stack currently uses the network core's support function
sock_alloc_send_skb() to allocate outgoing buffer space. It seems that
this is not designed for use with lock_sock()-based socket locking.
All other connection oriented protocols which apply lock_sock()
(currently only tcp and decnet) seem to implement their private equivalent
of sock_alloc_send_skb() which releases the lock while waiting for write
buffer space. Should I also do so for X.25 or would it make sense to
rework sock_alloc_send_skb() such that socket lock is released while
waiting for write buffer space?

With current BKL based locking, the kernel lock is released whenever
the process is waiting for GFP_KERNEL memory. But with lock_sock(),
the socket remains locked in such situations. Couldn't that cause
problems during low-memory conditions? The process could be blocked
-- with the lock hold -- for a rather long time.


While socket is locked, all incoming packets are queued at
sk->backlock without any precautions (neither seize limits nor
flow control affect sk->backlog queuing). It seems like feeding
lots of incoming packets while socket is locked could eat up
lots of kernel memory and even be exploited for a denial-of-service attack.


Henner

From owner-netdev@oss.sgi.com Mon Dec 18 15:35:51 2000
Received:  by oss.sgi.com id <S553744AbQLRXfm>;
	Mon, 18 Dec 2000 15:35:42 -0800
Received: from linuxcare.com.au ([203.29.91.49]:21509 "EHLO
        front.linuxcare.com.au") by oss.sgi.com with ESMTP
	id <S553667AbQLRXfY>; Mon, 18 Dec 2000 15:35:24 -0800
Received: from halfway (localhost [127.0.0.1])
	by front.linuxcare.com.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA09323;
	Tue, 19 Dec 2000 10:35:20 +1100
X-Authentication-Warning: front.linuxcare.com.au: Host localhost [127.0.0.1] claimed to be halfway
Received: from halfway
	([127.0.0.1] helo=linuxcare.com.au ident=rusty)
	by halfway with esmtp (Exim 3.20 #1 (Debian))
	id 1489oN-0000Tf-00; Tue, 19 Dec 2000 10:35:19 +1100
From:   Rusty Russell <rusty@linuxcare.com.au>
To:     netdev@oss.sgi.com
cc:     davem@redhat.com, anton@linuxcare.com, kuznet@ms2.inr.ac.ru,
        ak@muc.de
Subject: skb_linearize needs fixing?
Date:   Tue, 19 Dec 2000 10:35:19 +1100
Message-Id: <E1489oN-0000Tf-00@halfway>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

At the moment netfilter does a skb_linearize(), and the ip_queue_xmit2
dereferences skb->sk.  Boom (thanks Anton).

skb_linearize is different from skb_copy: it should copy the sk, list
and the destructor(?) (ie. be an identical copy).  I'd also prefer it to
return an int, and not free the old skb on failure (ie. int
skb_linearize(struct sk_buff **pskb)).

Oh, and inlining it seems, um, questionable.

Want a patch?
Rusty.
--
Hacking time.

From owner-netdev@oss.sgi.com Tue Dec 19 00:50:05 2000
Received:  by oss.sgi.com id <S553808AbQLSItp>;
	Tue, 19 Dec 2000 00:49:45 -0800
Received: from mail-out.chello.nl ([213.46.240.7]:43601 "EHLO
        amsmta06-svc.chello.nl") by oss.sgi.com with ESMTP
	id <S553687AbQLSIte>; Tue, 19 Dec 2000 00:49:34 -0800
Received: from server.serve.me.nl ([213.46.120.26])
          by amsmta06-svc.chello.nl
          (InterMail vK.4.02.00.10 201-232-116-110 license a20ebc008716c6ca05397a05e78c7098)
          with ESMTP
          id <20001219085031.SRNN23899.amsmta06-svc@server.serve.me.nl>;
          Tue, 19 Dec 2000 09:50:31 +0100
Date:   Tue, 19 Dec 2000 10:56:51 +0100 (CET)
From:   Igmar Palsenberg <maillist@chello.nl>
X-Sender: maillist@server.serve.me.nl
To:     jgoins@sunmine.com
cc:     Andrew Morton <andrewm@uow.edu.au>, netdev@oss.sgi.com,
        linux-kernel@vger.kernel.org
Subject: RE: Problem with 3c59x and 3C905B
In-Reply-To: <NCBBIGEIEDLIBLJACBEOEEECDGAA.jgoins@sunmine.com>
Message-ID: <Pine.LNX.4.21.0012191055170.9556-100000@server.serve.me.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, 18 Dec 2000 jgoins@sunmine.com wrote:

> Andrew Morton wrote:
> >
> > Working out why your switch isn't talking full-duplex would
> > probably make things work too, but it's not a fix.
> >
> 
> He said he has a 10/100 hub (NG DS104) -- it is a half-duplex only 10/100
> hub.

10/100 hub doesn't imply half-duplex to me. I've also got a 10/100 thingy,
but it is full duplex.

Bit that still doesn't explainn why the driver lies :)

> Regards,
> JGoins
> jgoins@sunmine.com


	Igmar


From owner-netdev@oss.sgi.com Tue Dec 19 06:41:46 2000
Received:  by oss.sgi.com id <S553740AbQLSOlg>;
	Tue, 19 Dec 2000 06:41:36 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:38922 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553728AbQLSOlX>;
	Tue, 19 Dec 2000 06:41:23 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id RAA13221; Tue, 19 Dec 2000 17:40:54 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012191440.RAA13221@ms2.inr.ac.ru>
Subject: Re: skb_linearize needs fixing?
To:     rusty@linuxcare.com.au (Rusty Russell)
Date:   Tue, 19 Dec 2000 17:40:54 +0300 (MSK)
Cc:     netdev@oss.sgi.com, davem@redhat.com, anton@linuxcare.com,
        ak@muc.de
In-Reply-To: <E1489oN-0000Tf-00@halfway> from "Rusty Russell" at Dec 19, 0 10:35:19 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 1007      
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> At the moment netfilter does a skb_linearize(), and the ip_queue_xmit2
> dereferences skb->sk.  Boom (thanks Anton).

Boom, agreed.

But what did you make with NAT earlier, when you also need to copy skb?
It is puzzle for me.


> skb_linearize is different from skb_copy: it should copy the sk, list
> and the destructor

This is impossible to do in core. Kind of ownership is known only
from context. Users used to set correct ownership of cloned/copied
buffers themselves, which in the case of netfilter happens always
write destructor.


> return an int, and not free the old skb on failure (ie. int
> skb_linearize(struct sk_buff **pskb)).

And what are you going to do with this skb after failure? 8)
It is clear: to free it, you have no more variants.

Apparently, you want to do plain skb_copy to copy ownership.
Yes, seems, the function copying write ownership should be exported too.

> Oh, and inlining it seems, um, questionable.

One line function is to be inlined, is not it?

Alexey

From owner-netdev@oss.sgi.com Tue Dec 19 07:18:05 2000
Received:  by oss.sgi.com id <S553767AbQLSPRp>;
	Tue, 19 Dec 2000 07:17:45 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:64522 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553757AbQLSPRT>;
	Tue, 19 Dec 2000 07:17:19 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id SAA13781; Tue, 19 Dec 2000 18:16:53 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012191516.SAA13781@ms2.inr.ac.ru>
Subject: Re: migrating to lock_sock()
To:     eis@baty.hanse.DE (Henner Eisen)
Date:   Tue, 19 Dec 2000 18:16:53 +0300 (MSK)
Cc:     netdev@oss.sgi.com
In-Reply-To: <200012182206.XAA03137@baty.hanse.de> from "Henner Eisen" at Dec 19, 0 01:45:01 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 324       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> buffer space. Should I also do so for X.25 or would it make sense to
> rework sock_alloc_send_skb() such that socket lock is released while
> waiting for write buffer space?

sock_alloc_send_skb() is stateless, there is no lock to release.

If your protocol uses socket lock, you cannot use this function.

Alexey

From owner-netdev@oss.sgi.com Tue Dec 19 07:33:06 2000
Received:  by oss.sgi.com id <S553762AbQLSPcq>;
	Tue, 19 Dec 2000 07:32:46 -0800
Received: from smtp1.cern.ch ([137.138.128.38]:4100 "EHLO smtp1.cern.ch")
	by oss.sgi.com with ESMTP id <S553657AbQLSPcS>;
	Tue, 19 Dec 2000 07:32:18 -0800
Received: from lxplus015.cern.ch (IDENT:root@lxplus015.cern.ch [137.138.161.112])
	by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id QAA22719;
	Tue, 19 Dec 2000 16:32:11 +0100 (MET)
Received: (from jes@localhost)
	by lxplus015.cern.ch (8.9.3/8.9.3) id QAA30871;
	Tue, 19 Dec 2000 16:32:10 +0100
To:     kuznet@ms2.inr.ac.ru
Cc:     netdev@oss.sgi.com, davem@redhat.com
Subject: Re: alignment issues on netif_rx
References: <200012182031.XAA00572@ms2.inr.ac.ru>
From:   Jes Sorensen <jes@linuxcare.com>
Date:   19 Dec 2000 16:32:10 +0100
In-Reply-To: kuznet@ms2.inr.ac.ru's message of "Mon, 18 Dec 2000 23:31:37 +0300 (MSK)"
Message-ID: <d3elz45sw5.fsf@lxplus015.cern.ch>
Lines:  12
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "ANK" == kuznet  <kuznet@ms2.inr.ac.ru> writes:

ANK> Hello!
>> This still requires that the card can DMA to multiple buffers,

ANK> If they cannot dma to not aligned buffers, scatter dma is
ANK> meaningless in any case.

Thats why I suggested the misaligned-word loads, otherwise we have to
copy both Ethernet and IP/TCP/UDP headers.

Jes

From owner-netdev@oss.sgi.com Tue Dec 19 07:53:25 2000
Received:  by oss.sgi.com id <S553771AbQLSPxP>;
	Tue, 19 Dec 2000 07:53:15 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:24075 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553720AbQLSPwt>;
	Tue, 19 Dec 2000 07:52:49 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id SAA14335; Tue, 19 Dec 2000 18:52:27 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012191552.SAA14335@ms2.inr.ac.ru>
Subject: Re: alignment issues on netif_rx
To:     jes@linuxcare.com (Jes Sorensen)
Date:   Tue, 19 Dec 2000 18:52:27 +0300 (MSK)
Cc:     netdev@oss.sgi.com, davem@redhat.com
In-Reply-To: <d3elz45sw5.fsf@lxplus015.cern.ch> from "Jes Sorensen" at Dec 19, 0 04:32:10 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 275       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Thats why I suggested the misaligned-word loads, otherwise we have to
> copy both Ethernet and IP/TCP/UDP headers.

Thats why I suggested to copy a few of headers in a few of weird cases,
otherwise we have to do misaligned-word loads over all the stack. 8)

Alexey

From owner-netdev@oss.sgi.com Tue Dec 19 09:37:15 2000
Received:  by oss.sgi.com id <S553796AbQLSRhF>;
	Tue, 19 Dec 2000 09:37:05 -0800
Received: from battlejitney.wdhq.scyld.com ([216.254.93.178]:53231 "EHLO
        vaio.greennet") by oss.sgi.com with ESMTP id <S553783AbQLSRgl>;
	Tue, 19 Dec 2000 09:36:41 -0800
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id MAA04238;
	Tue, 19 Dec 2000 12:43:44 -0500
Date:   Tue, 19 Dec 2000 12:43:43 -0500 (EST)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     kuznet@ms2.inr.ac.ru
cc:     Jes Sorensen <jes@linuxcare.com>, netdev@oss.sgi.com,
        davem@redhat.com
Subject: Re: alignment issues on netif_rx
In-Reply-To: <200012191552.SAA14335@ms2.inr.ac.ru>
Message-ID: <Pine.LNX.4.10.10012191225230.1126-100000@vaio.greennet>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, 19 Dec 2000 kuznet@ms2.inr.ac.ru wrote:

> > Thats why I suggested the misaligned-word loads, otherwise we have to
> > copy both Ethernet and IP/TCP/UDP headers.
> 
> Thats why I suggested to copy a few of headers in a few of weird cases,
> otherwise we have to do misaligned-word loads over all the stack. 8)

You will have to do mis-aligned word loads _somewhere_.

Ethernet cards do not look at the encapsulation type.  They just store the
packet into the receive buffer.  Since almost all Ethernet packets are in DIX
format (2 byte protocol field, no length field), that is the preferred
default alignment.

BTW, a common thought process for descriptor-based cards is
"I'll receive the 14 byte header into one fragment, and then the IP header
will be word aligned in the next fragment."  But every chip that has a
word-alignment-only restriction on the Rx buffers also has a
multiple-of-4-only restriction on the Rx buffer size, so you can't change
the header alignment written out by the hardware.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993


From owner-netdev@oss.sgi.com Tue Dec 19 09:48:05 2000
Received:  by oss.sgi.com id <S553801AbQLSRr4>;
	Tue, 19 Dec 2000 09:47:56 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:4620 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553795AbQLSRrw>;
	Tue, 19 Dec 2000 09:47:52 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA15274; Tue, 19 Dec 2000 20:47:26 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012191747.UAA15274@ms2.inr.ac.ru>
Subject: Re: alignment issues on netif_rx
To:     becker@scyld.com (Donald Becker)
Date:   Tue, 19 Dec 2000 20:47:25 +0300 (MSK)
Cc:     jes@linuxcare.com, netdev@oss.sgi.com, davem@redhat.com
In-Reply-To: <Pine.LNX.4.10.10012191225230.1126-100000@vaio.greennet> from "Donald Becker" at Dec 19, 0 12:43:43 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 223       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> You will have to do mis-aligned word loads _somewhere_.

No doubts. Copy is misaligned access too. 8)


> 						so you can't change
> the header alignment written out by the hardware.

Keyword was "copy".

Alexey

From owner-netdev@oss.sgi.com Tue Dec 19 10:35:45 2000
Received:  by oss.sgi.com id <S553828AbQLSSf0>;
	Tue, 19 Dec 2000 10:35:26 -0800
Received: from smtp1.cern.ch ([137.138.128.38]:62734 "EHLO smtp1.cern.ch")
	by oss.sgi.com with ESMTP id <S553818AbQLSSfZ>;
	Tue, 19 Dec 2000 10:35:25 -0800
Received: from lxplus015.cern.ch (IDENT:root@lxplus015.cern.ch [137.138.161.112])
	by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id TAA26895;
	Tue, 19 Dec 2000 19:35:18 +0100 (MET)
Received: (from jes@localhost)
	by lxplus015.cern.ch (8.9.3/8.9.3) id TAA05889;
	Tue, 19 Dec 2000 19:35:18 +0100
To:     kuznet@ms2.inr.ac.ru
Cc:     netdev@oss.sgi.com, davem@redhat.com
Subject: Re: alignment issues on netif_rx
References: <200012191552.SAA14335@ms2.inr.ac.ru>
From:   Jes Sorensen <jes@linuxcare.com>
Date:   19 Dec 2000 19:35:17 +0100
In-Reply-To: kuznet@ms2.inr.ac.ru's message of "Tue, 19 Dec 2000 18:52:27 +0300 (MSK)"
Message-ID: <d3ae9s5key.fsf@lxplus015.cern.ch>
Lines:  13
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "kuznet" == kuznet  <kuznet@ms2.inr.ac.ru> writes:

kuznet> Hello!
>> Thats why I suggested the misaligned-word loads, otherwise we have
>> to copy both Ethernet and IP/TCP/UDP headers.

kuznet> Thats why I suggested to copy a few of headers in a few of
kuznet> weird cases, otherwise we have to do misaligned-word loads
kuznet> over all the stack. 8)

The question is how much to copy.

Jes

From owner-netdev@oss.sgi.com Tue Dec 19 10:50:35 2000
Received:  by oss.sgi.com id <S553770AbQLSSu0>;
	Tue, 19 Dec 2000 10:50:26 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:49420 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553652AbQLSSuL>;
	Tue, 19 Dec 2000 10:50:11 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA16069; Tue, 19 Dec 2000 21:49:49 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012191849.VAA16069@ms2.inr.ac.ru>
Subject: Re: alignment issues on netif_rx
To:     jes@linuxcare.com (Jes Sorensen)
Date:   Tue, 19 Dec 2000 21:49:49 +0300 (MSK)
Cc:     netdev@oss.sgi.com, davem@redhat.com
In-Reply-To: <d3ae9s5key.fsf@lxplus015.cern.ch> from "Jes Sorensen" at Dec 19, 0 07:35:17 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 140       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> The question is how much to copy.

The answer is instant: MAC header only. 8)

All the rest will be pulled out on demand.

Alexey

From owner-netdev@oss.sgi.com Tue Dec 19 12:31:25 2000
Received:  by oss.sgi.com id <S553818AbQLSUbQ>;
	Tue, 19 Dec 2000 12:31:16 -0800
Received: from smtp1.cern.ch ([137.138.128.38]:46865 "EHLO smtp1.cern.ch")
	by oss.sgi.com with ESMTP id <S553809AbQLSUau>;
	Tue, 19 Dec 2000 12:30:50 -0800
Received: from lxplus015.cern.ch (IDENT:root@lxplus015.cern.ch [137.138.161.112])
	by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id VAA19602;
	Tue, 19 Dec 2000 21:30:43 +0100 (MET)
Received: (from jes@localhost)
	by lxplus015.cern.ch (8.9.3/8.9.3) id VAA21233;
	Tue, 19 Dec 2000 21:30:42 +0100
To:     kuznet@ms2.inr.ac.ru
Cc:     netdev@oss.sgi.com, davem@redhat.com
Subject: Re: alignment issues on netif_rx
References: <200012191849.VAA16069@ms2.inr.ac.ru>
From:   Jes Sorensen <jes@linuxcare.com>
Date:   19 Dec 2000 21:30:42 +0100
In-Reply-To: kuznet@ms2.inr.ac.ru's message of "Tue, 19 Dec 2000 21:49:49 +0300 (MSK)"
Message-ID: <d31yv45f2l.fsf@lxplus015.cern.ch>
Lines:  15
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "ANK" == kuznet  <kuznet@ms2.inr.ac.ru> writes:

ANK> Hello!
>> The question is how much to copy.

ANK> The answer is instant: MAC header only. 8)

ANK> All the rest will be pulled out on demand.

Thats where your suggestion fails, we then have to copy the entire
packet then for the cards that disallow misaligned DMAs. My idea to
add the misaligned word access would work.

Jes


From owner-netdev@oss.sgi.com Tue Dec 19 12:33:46 2000
Received:  by oss.sgi.com id <S553814AbQLSUdg>;
	Tue, 19 Dec 2000 12:33:36 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:24077 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553799AbQLSUdZ>;
	Tue, 19 Dec 2000 12:33:25 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA16718; Tue, 19 Dec 2000 23:33:07 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012192033.XAA16718@ms2.inr.ac.ru>
Subject: Re: alignment issues on netif_rx
To:     jes@linuxcare.com (Jes Sorensen)
Date:   Tue, 19 Dec 2000 23:33:07 +0300 (MSK)
Cc:     netdev@oss.sgi.com, davem@redhat.com
In-Reply-To: <d31yv45f2l.fsf@lxplus015.cern.ch> from "Jes Sorensen" at Dec 19, 0 09:30:42 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 172       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Thats where your suggestion fails, we then have to copy the entire
> packet

I started from the statment: now we may have header separate of body.
See?


Alexey


From owner-netdev@oss.sgi.com Tue Dec 19 15:44:27 2000
Received:  by oss.sgi.com id <S553846AbQLSXoQ>;
	Tue, 19 Dec 2000 15:44:16 -0800
Received: from kogge.hanse.de ([192.76.134.17]:6918 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S553837AbQLSXoF>;
	Tue, 19 Dec 2000 15:44:05 -0800
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id AAA51103
	for netdev@oss.sgi.com; Wed, 20 Dec 2000 00:43:47 +0100 (CET)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id AAA11827;
	Wed, 20 Dec 2000 00:32:35 +0100
Date:   Wed, 20 Dec 2000 00:32:35 +0100
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200012192332.AAA11827@baty.hanse.de>
To:     netdev@oss.sgi.com
Subject: lapb module irq context problems
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Hi,

some lapb network device drivers might currently call the interface
routines to tha lapb protocol engine (in particular lapb_data_received())
from hardware irq. That causes problems with 2.4.0 softnet when
sk_buff's are kfree'd.

There three options to fix this:

1) replace all kfree_skb() by kfree_skb_any() (patch, already available)
2) change all affected drivers question to defer skb processing to
   a buttom handler/softirq.
3) provide an additional interface `lapb_data_received_irq()', which
   just queues the incoming frame and defers execution of
   `lapb_data_received()' to a buttom handler/softirq.

I think 2 or 3 will be the better solution because processing the lapb
protocol entirly from hardware irq is not something the 2.4 networking
core / softnet is designed for. However they are more difficult to
implement. 3) only requries to implement it once and all drivers can be
fixed easily after this. Thus, I'd prefer 3).

With 3, there are two options
a) the lapb module mantains an own backlog queue and schedules a tasklet
   that dequeues and processess the incoming frame.
b) the lapb module creates a `pseudo' network interface and a packet handler,
   incoming frames are queued to the standard network interface backlog
   queue by means of netif_rx() and the packet handler basically calls
   lapb_data_received().

I'd prefer b), or are there any reasons to favor another approach?

Henner

From owner-netdev@oss.sgi.com Tue Dec 19 15:44:46 2000
Received:  by oss.sgi.com id <S553847AbQLSXo1>;
	Tue, 19 Dec 2000 15:44:27 -0800
Received: from kogge.hanse.de ([192.76.134.17]:7430 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S553845AbQLSXoL>;
	Tue, 19 Dec 2000 15:44:11 -0800
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id AAA51104;
	Wed, 20 Dec 2000 00:44:06 +0100 (CET)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id AAA11831;
	Wed, 20 Dec 2000 00:36:33 +0100
Date:   Wed, 20 Dec 2000 00:36:33 +0100
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200012192336.AAA11831@baty.hanse.de>
To:     kuznet@ms2.inr.ac.ru
CC:     netdev@oss.sgi.com
In-reply-to: <200012191516.SAA13781@ms2.inr.ac.ru> (kuznet@ms2.inr.ac.ru)
Subject: Re: migrating to lock_sock()
References:  <200012191516.SAA13781@ms2.inr.ac.ru>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "kuznet" == kuznet  <kuznet@ms2.inr.ac.ru> writes:

    kuznet> sock_alloc_send_skb() is stateless, there is no lock to
    kuznet> release.

    kuznet> If your protocol uses socket lock, you cannot use this
    kuznet> function.

o.k., thus I need to implement an own function. Would it make sense
to implement it inside the network core such that other protocols
that want to migrate to lock_sock() locking can re-use it?

Henner

From owner-netdev@oss.sgi.com Tue Dec 19 16:15:46 2000
Received:  by oss.sgi.com id <S553845AbQLTAPh>;
	Tue, 19 Dec 2000 16:15:37 -0800
Received: from smtp1.cern.ch ([137.138.128.38]:5392 "EHLO smtp1.cern.ch")
	by oss.sgi.com with ESMTP id <S553785AbQLTAPS>;
	Tue, 19 Dec 2000 16:15:18 -0800
Received: from lxplus015.cern.ch (IDENT:root@lxplus015.cern.ch [137.138.161.112])
	by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id BAA26483;
	Wed, 20 Dec 2000 01:15:11 +0100 (MET)
Received: (from jes@localhost)
	by lxplus015.cern.ch (8.9.3/8.9.3) id BAA18479;
	Wed, 20 Dec 2000 01:15:11 +0100
To:     kuznet@ms2.inr.ac.ru
Cc:     netdev@oss.sgi.com, davem@redhat.com
Subject: Re: alignment issues on netif_rx
References: <200012192033.XAA16718@ms2.inr.ac.ru>
From:   Jes Sorensen <jes@linuxcare.com>
Date:   20 Dec 2000 01:15:11 +0100
In-Reply-To: kuznet@ms2.inr.ac.ru's message of "Tue, 19 Dec 2000 23:33:07 +0300 (MSK)"
Message-ID: <d3vgsgx81c.fsf@lxplus015.cern.ch>
Lines:  13
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "ANK" == kuznet  <kuznet@ms2.inr.ac.ru> writes:

ANK> Hello!
>> Thats where your suggestion fails, we then have to copy the entire
>> packet

ANK> I started from the statment: now we may have header separate of
ANK> body.  See?

I follow you but then we are back in a situation where we haven't
solved the problem.

Jes

From owner-netdev@oss.sgi.com Tue Dec 19 16:46:37 2000
Received:  by oss.sgi.com id <S553853AbQLTAq0>;
	Tue, 19 Dec 2000 16:46:26 -0800
Received: from e4.ny.us.ibm.com ([32.97.182.104]:53175 "EHLO e4.ny.us.ibm.com")
	by oss.sgi.com with ESMTP id <S553655AbQLTAqX>;
	Tue, 19 Dec 2000 16:46:23 -0800
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA141332
	for <netdev@oss.sgi.com>; Tue, 19 Dec 2000 19:45:36 -0500
Received: from d01ml233.pok.ibm.com (d01ml233.pok.ibm.com [9.117.200.63])
	by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id TAA195970
	for <netdev@oss.sgi.com>; Tue, 19 Dec 2000 19:44:14 -0500
Importance: Normal
Subject: CBQ performance?
To:     netdev@oss.sgi.com
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF14604B05.BB4C915D-ON852569BB.0003DAFE@pok.ibm.com>
From:   "Kang-won Lee" <kangwon@us.ibm.com>
Date:   Tue, 19 Dec 2000 19:46:20 -0500
X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Build V506_12112000 |December 11, 2000) at
 12/19/2000 07:46:21 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi,
Has anyone looked at the performance of the Linux 2.4 CBQ implementation?
How accurate/stable it is...
Any pointer would be a great help.
Thanks,

Kang-Won Lee
IBM T.J. Watson Research
Hawthorne, NY 10532


From owner-netdev@oss.sgi.com Tue Dec 19 17:40:46 2000
Received:  by oss.sgi.com id <S553874AbQLTBkg>;
	Tue, 19 Dec 2000 17:40:36 -0800
Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:55812 "EHLO
        grok.yi.org") by oss.sgi.com with ESMTP id <S553675AbQLTBkV>;
	Tue, 19 Dec 2000 17:40:21 -0800
Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1])
	by grok.yi.org (8.9.3/8.8.7) with ESMTP id TAA21535;
	Tue, 19 Dec 2000 19:41:17 -0700
Message-ID: <3A401C4D.582145E4@candelatech.com>
Date:   Tue, 19 Dec 2000 19:41:17 -0700
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Donald Becker <becker@scyld.com>
CC:     kuznet@ms2.inr.ac.ru, Jes Sorensen <jes@linuxcare.com>,
        netdev@oss.sgi.com, davem@redhat.com
Subject: Re: alignment issues on netif_rx
References: <Pine.LNX.4.10.10012191225230.1126-100000@vaio.greennet>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Donald Becker wrote:
> 
> On Tue, 19 Dec 2000 kuznet@ms2.inr.ac.ru wrote:
> 
> > > Thats why I suggested the misaligned-word loads, otherwise we have to
> > > copy both Ethernet and IP/TCP/UDP headers.
> >
> > Thats why I suggested to copy a few of headers in a few of weird cases,
> > otherwise we have to do misaligned-word loads over all the stack. 8)
> 
> You will have to do mis-aligned word loads _somewhere_.
> 
> Ethernet cards do not look at the encapsulation type.  They just store the
> packet into the receive buffer.  Since almost all Ethernet packets are in DIX
> format (2 byte protocol field, no length field), that is the preferred
> default alignment.
> 
> BTW, a common thought process for descriptor-based cards is
> "I'll receive the 14 byte header into one fragment, and then the IP header
> will be word aligned in the next fragment."  But every chip that has a
> word-alignment-only restriction on the Rx buffers also has a
> multiple-of-4-only restriction on the Rx buffer size, so you can't change
> the header alignment written out by the hardware.

Sounds like it might also break 802.1Q/P, since it has a slightly
larger header (18 bytes total).  If you could detect 802.1Q before
you pulled the header, then you could do variable-length pulls, but
that doesn't sound like much fun...

Ben

> 
> Donald Becker                           becker@scyld.com
> Scyld Computing Corporation             http://www.scyld.com
> 410 Severn Ave. Suite 210               Second Generation Beowulf Clusters
> Annapolis MD 21403                      410-990-9993

-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

From owner-netdev@oss.sgi.com Tue Dec 19 20:29:49 2000
Received:  by oss.sgi.com id <S553884AbQLTE3j>;
	Tue, 19 Dec 2000 20:29:39 -0800
Received: from laurin.munich.netsurf.de ([194.64.166.1]:61618 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S553880AbQLTE3T>; Tue, 19 Dec 2000 20:29:19 -0800
Received: from fred.muc.de (noidentity@ns1140.munich.netsurf.de [195.180.235.140])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id FAA17100;
	Wed, 20 Dec 2000 05:28:59 +0100 (MET)
Received: by fred.muc.de (Postfix, from userid 500)
	id 651B6E3919; Wed, 20 Dec 2000 05:34:37 +0100 (CET)
Date:   Wed, 20 Dec 2000 05:34:37 +0100
From:   Andi Kleen <ak@muc.de>
To:     Jes Sorensen <jes@linuxcare.com>
Cc:     kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, davem@redhat.com
Subject: Re: alignment issues on netif_rx
Message-ID: <20001220053437.A1835@fred.local>
References: <200012191849.VAA16069@ms2.inr.ac.ru> <d31yv45f2l.fsf@lxplus015.cern.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <d31yv45f2l.fsf@lxplus015.cern.ch>; from jes@linuxcare.com on Tue, Dec 19, 2000 at 09:32:14PM +0100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, Dec 19, 2000 at 09:32:14PM +0100, Jes Sorensen wrote:
> >>>>> "ANK" == kuznet  <kuznet@ms2.inr.ac.ru> writes:
> 
> ANK> Hello!
> >> The question is how much to copy.
> 
> ANK> The answer is instant: MAC header only. 8)
> 
> ANK> All the rest will be pulled out on demand.
> 
> Thats where your suggestion fails, we then have to copy the entire
> packet then for the cards that disallow misaligned DMAs. My idea to
> add the misaligned word access would work.

Copying the header is identical to misaligned word accesses, except
that a small cache is put inbetween ;) 

Doing it explicitely would be no replacement for kernel mode misalignment handlers 
though: when you make any mistake (and there are lots of places for that)
you have a remote exploitable kernel panic.

There is also probably other code in the kernel that has the same problem.

-Andi

From owner-netdev@oss.sgi.com Wed Dec 20 09:49:51 2000
Received:  by oss.sgi.com id <S553895AbQLTRtm>;
	Wed, 20 Dec 2000 09:49:42 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:3083 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553717AbQLTRtX>;
	Wed, 20 Dec 2000 09:49:23 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA02642; Wed, 20 Dec 2000 20:48:56 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012201748.UAA02642@ms2.inr.ac.ru>
Subject: Re: alignment issues on netif_rx
To:     jes@linuxcare.com (Jes Sorensen)
Date:   Wed, 20 Dec 2000 20:48:56 +0300 (MSK)
Cc:     netdev@oss.sgi.com, davem@redhat.com
In-Reply-To: <d31yv45f2l.fsf@lxplus015.cern.ch> from "Jes Sorensen" at Dec 19, 0 09:30:42 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 263       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> ANK> All the rest will be pulled out on demand.
> 
> Thats where your suggestion fails, we then have to copy the entire
> packet then for the cards that disallow misaligned DMAs.

You still did not understand. We need not copy data more. Never.

Alexey

From owner-netdev@oss.sgi.com Wed Dec 20 09:55:11 2000
Received:  by oss.sgi.com id <S553911AbQLTRyw>;
	Wed, 20 Dec 2000 09:54:52 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:7691 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553893AbQLTRyi>;
	Wed, 20 Dec 2000 09:54:38 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA02687; Wed, 20 Dec 2000 20:54:20 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012201754.UAA02687@ms2.inr.ac.ru>
Subject: Re: migrating to lock_sock()
To:     eis@baty.hanse.de (Henner Eisen)
Date:   Wed, 20 Dec 2000 20:54:20 +0300 (MSK)
Cc:     netdev@oss.sgi.com
In-Reply-To: <200012192336.AAA11831@baty.hanse.de> from "Henner Eisen" at Dec 20, 0 00:36:33 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 523       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> o.k., thus I need to implement an own function. Would it make sense
> to implement it inside the network core such that other protocols
> that want to migrate to lock_sock() locking can re-use it?

Well, you are the first who needs it. 8)

Probably. Actually, it is not very clear. Stateful protocols
(f.e. TCP) have their own wakeup predicates.

In fact, sock_alloc_send_skb() is typical example of wrong function:
it tries to satisfy everyone (f.e. fallback allocation is used only
by af_unix streams).

Alexey

From owner-netdev@oss.sgi.com Wed Dec 20 10:38:11 2000
Received:  by oss.sgi.com id <S553912AbQLTShw>;
	Wed, 20 Dec 2000 10:37:52 -0800
Received: from pizda.ninka.net ([216.101.162.242]:19601 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S553893AbQLTShc>;
	Wed, 20 Dec 2000 10:37:32 -0800
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id KAA10981;
	Wed, 20 Dec 2000 10:20:48 -0800
Date:   Wed, 20 Dec 2000 10:20:48 -0800
Message-Id: <200012201820.KAA10981@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     eis@baty.hanse.de
CC:     netdev@oss.sgi.com
In-reply-to: <200012192332.AAA11827@baty.hanse.de> (message from Henner Eisen
	on Wed, 20 Dec 2000 00:32:35 +0100)
Subject: Re: lapb module irq context problems
References:  <200012192332.AAA11827@baty.hanse.de>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date:   Wed, 20 Dec 2000 00:32:35 +0100
   From: Henner Eisen <eis@baty.hanse.de>

   With 3, there are two options
   a) the lapb module mantains an own backlog queue and schedules a tasklet
      that dequeues and processess the incoming frame.
   b) the lapb module creates a `pseudo' network interface and a packet handler,
      incoming frames are queued to the standard network interface backlog
      queue by means of netif_rx() and the packet handler basically calls
      lapb_data_received().

   I'd prefer b), or are there any reasons to favor another approach?

I would recommend to do #3 but make it identical to
lapb_data_received() except that it explicitly uses kfree_skb_irq().
Let the core networking "defer to softnet" this action for you.

Or does something prevent such a straight-forward transformation?

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Wed Dec 20 11:37:33 2000
Received:  by oss.sgi.com id <S553916AbQLTThM>;
	Wed, 20 Dec 2000 11:37:12 -0800
Received: from smtp1.cern.ch ([137.138.128.38]:16903 "EHLO smtp1.cern.ch")
	by oss.sgi.com with ESMTP id <S553913AbQLTThH>;
	Wed, 20 Dec 2000 11:37:07 -0800
Received: from lxplus015.cern.ch (IDENT:root@lxplus015.cern.ch [137.138.161.112])
	by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id UAA17992;
	Wed, 20 Dec 2000 20:37:00 +0100 (MET)
Received: (from jes@localhost)
	by lxplus015.cern.ch (8.9.3/8.9.3) id UAA14018;
	Wed, 20 Dec 2000 20:36:59 +0100
To:     kuznet@ms2.inr.ac.ru
Cc:     netdev@oss.sgi.com, davem@redhat.com
Subject: Re: alignment issues on netif_rx
References: <200012201748.UAA02642@ms2.inr.ac.ru>
From:   Jes Sorensen <jes@linuxcare.com>
Date:   20 Dec 2000 20:36:59 +0100
In-Reply-To: kuznet@ms2.inr.ac.ru's message of "Wed, 20 Dec 2000 20:48:56 +0300 (MSK)"
Message-ID: <d3wvcuq3z8.fsf@lxplus015.cern.ch>
Lines:  14
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "ANK" == kuznet  <kuznet@ms2.inr.ac.ru> writes:

ANK> Hello!  All the rest will be pulled out on demand.
>>  Thats where your suggestion fails, we then have to copy the entire
>> packet then for the cards that disallow misaligned DMAs.

ANK> You still did not understand. We need not copy data more. Never.

Yes I did - you said we should only split off the Ethernet header but
as Don stated in his email some cards wont allow non-word length DMA
transactions either. Hence you cannot split off a 14 byte header and
get your IP+TCP headers aligned.

Jes

From owner-netdev@oss.sgi.com Wed Dec 20 11:49:12 2000
Received:  by oss.sgi.com id <S553917AbQLTTtC>;
	Wed, 20 Dec 2000 11:49:02 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:19724 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553915AbQLTTss>;
	Wed, 20 Dec 2000 11:48:48 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA04160; Wed, 20 Dec 2000 22:48:27 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200012201948.WAA04160@ms2.inr.ac.ru>
Subject: Re: alignment issues on netif_rx
To:     jes@linuxcare.com (Jes Sorensen)
Date:   Wed, 20 Dec 2000 22:48:27 +0300 (MSK)
Cc:     netdev@oss.sgi.com, davem@redhat.com
In-Reply-To: <d3wvcuq3z8.fsf@lxplus015.cern.ch> from "Jes Sorensen" at Dec 20, 0 08:36:59 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 746       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Yes I did - you said we should only split off the Ethernet header but
> as Don stated in his email some cards wont allow non-word length DMA
> transactions either. Hence you cannot split off a 14 byte header and
> get your IP+TCP headers aligned.

DMA has nothing to do with this. At all. This happens each time
when encapsulation is badly designed like ethernetII,
ISDN is another example.

If alignment is wrong, it can restored without copying data.
This happens automatically, as soon as alignment is guessed.
Particularly, if driver copies EthernetII MAC header to finish
aligned at 4 byte boundary, no more unaligned accesses will happen.
Headers are fetched with memcpy to correclty aligned area,
when they are required.

Alexey

From owner-netdev@oss.sgi.com Wed Dec 20 14:48:32 2000
Received:  by oss.sgi.com id <S553929AbQLTWsM>;
	Wed, 20 Dec 2000 14:48:12 -0800
Received: from lsi.lsil.com ([147.145.40.2]:61846 "EHLO lsi.lsil.com")
	by oss.sgi.com with ESMTP id <S553914AbQLTWr7>;
	Wed, 20 Dec 2000 14:47:59 -0800
Received: from mhbs.lsil.com (mhbs [147.145.31.100])
	by lsi.lsil.com (8.9.3+Sun/8.9.1) with ESMTP id OAA04692
	for <netdev@oss.sgi.com>; Wed, 20 Dec 2000 14:47:50 -0800 (PST)
Received: from inca.co.lsil.com by mhbs.lsil.com with ESMTP for netdev@oss.sgi.com; Wed, 20 Dec 2000 14:46:34 -0800
Received: from exw-kansas.ks.lsil.com (exw-kansas.ks.lsil.com [153.79.8.7])
	by inca.co.lsil.com (8.9.3/8.9.3) with ESMTP id PAA25533;
	Wed, 20 Dec 2000 15:46:33 -0700 (MST)
Received: from lsil.com (nromernt.ks.lsil.com [153.79.8.107]) by exw-kansas.ks.lsil.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id Y8J92MZ0; Wed, 20 Dec 2000 16:44:57 -0600
Message-Id: <3A40E268.F844EC2@lsil.com>
Date:   Wed, 20 Dec 2000 11:46:32 -0500
From:   Noah Romer <nromer@lsil.com>
Organization: LSI Logic
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev@oss.sgi.com
CC:     noah.romer@lsil.com
Subject: [PATCH] accept ARP's with HW Type of 1 from IEEE802 devices
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Patch against linux/net/ipv4/arp.c to accept ARP's with HW Type of 1 from
IEEE802 devices (specifically, Fibre Channel devices). This has been tested
with linux-2.4.0-test9 and linux-2.4.0-test12.

---
diff -u arp.c~ arp.c
--- arp.c~      Tue Oct  3 09:24:41 2000
+++ arp.c       Wed Dec 20 16:05:36 2000
@@ -647,6 +647,20 @@
                        goto out;
                break;
 #endif
+#ifdef CONFIG_NET_FC
+       case ARPHRD_IEEE802:
+               /*
+                * According to RFC 2625, Fibre Channel devices (which are IEEE
+                * 802 devices) should accept ARP hardware types of 6 (IEEE
802)
+                * and 1 (Ethernet).
+                */
+               if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) &&
+                   arp->ar_hrd != __constant_htons(ARPHRD_IEEE802))
+                       goto out;
+               if (arp->ar_pro != __constant_htons(ETH_P_IP))
+                       goto out;
+               break;
+#endif
 #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
        case ARPHRD_AX25:
                if (arp->ar_pro != __constant_htons(AX25_P_IP))

From owner-netdev@oss.sgi.com Thu Dec 21 19:10:33 2000
Received:  by oss.sgi.com id <S553646AbQLVDKN>;
	Thu, 21 Dec 2000 19:10:13 -0800
Received: from smtp03.mrf.mail.rcn.net ([207.172.4.62]:15066 "EHLO
        smtp03.mrf.mail.rcn.net") by oss.sgi.com with ESMTP
	id <S553664AbQLVATY>; Thu, 21 Dec 2000 16:19:24 -0800
Received: from 66-44-54-164.s164.tnt1.lnhva.md.dialup.rcn.com ([66.44.54.164] helo=hdo)
	by smtp03.mrf.mail.rcn.net with smtp (Exim 3.16 #5)
	id 149EpZ-0001Yu-00 
	for netdev@oss.sgi.com; Thu, 21 Dec 2000 18:09:01 -0500
Message-ID: <009f01c06ba2$ff4108a0$3365a8c0@hdo>
Reply-To: "Hoa Do" <HoaDo@signafor.com>
From:   "Hoa Do" <HoaDo@signafor.com>
To:     <netdev@oss.sgi.com>
Subject: Weighted Fair Queue implementation for Linux
Date:   Thu, 21 Dec 2000 18:08:56 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_009C_01C06B79.15C327E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_009C_01C06B79.15C327E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

I am currently looking for a WFQ implementation for Linux kernel (either =
2.2 or 2.4) ?

Do you know who has developed one for Linux ?

Any help would be greatly appreciated.
=20
Thanks,
Hoa.


------=_NextPart_000_009C_01C06B79.15C327E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I am currently looking for a WFQ =
implementation for=20
Linux kernel (either 2.2 or 2.4) ?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Do you know who has developed one for =
Linux=20
?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Any help would be greatly =
appreciated.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Hoa.</FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_009C_01C06B79.15C327E0--


From owner-netdev@oss.sgi.com Thu Dec 21 21:16:12 2000
Received:  by oss.sgi.com id <S553671AbQLVFPw>;
	Thu, 21 Dec 2000 21:15:52 -0800
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:24581 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S553645AbQLVFPr>; Thu, 21 Dec 2000 21:15:47 -0800
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id OAA08981;
	Fri, 22 Dec 2000 14:14:34 +0900
To:     kuznet@ms2.inr.ac.ru
Cc:     netdev@oss.sgi.com
Subject: Re: skb->dev = NULL in tcp_v{4,6}_rcv()
In-Reply-To: <200012212033.XAA05009@ms2.inr.ac.ru>
References: <20001222044900Z.yoshfuji@ecei.tohoku.ac.jp>
	<200012212033.XAA05009@ms2.inr.ac.ru>
X-Mailer: Mew version 1.94 on XEmacs 21.1 (Capitol Reef)
X-URL:  http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20001222141431S.yoshfuji@ecei.tohoku.ac.jp>
Date:   Fri, 22 Dec 2000 14:14:31 +0900
From:   YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= 
        <yoshfuji@ecei.tohoku.ac.jp>
X-Dispatcher: imput version 990905(IM130)
Lines:  29
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In article <200012212033.XAA05009@ms2.inr.ac.ru> (at Thu, 21 Dec 2000 23:33:47 +0300 (MSK)), kuznet@ms2.inr.ac.ru says:

> > If so, how can I get "dev" in tcp_v{4,6}_do_rcv()?
> 
> No way. Device may even not exist to time when skb reaches these functions.
> You can get its index in the way like it is obtained there now,
> look into code. Device can be looked up by index, but the lookup may fail.

Thanks.  Now we use tcp_v6_iif() and dev_get_by_index() 
in tcp_v6_do_rcv():

   struct net_device *dev;
   struct inet6_dev *idev;
:
   dev = dev_get_by_index(tcp_v6_iif(skb));
   idev = dev ? in6_dev_get(dev) : NULL;
   
   /* do idev related things; (idev may be NULL) */

   if (dev){
      if (idev)
         in6_dev_put(idev);
      dev_put(dev);
   }
:

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@linux-ipv6.org>
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Fri Dec 22 08:39:28 2000
Received:  by oss.sgi.com id <S553742AbQLVQjJ>;
	Fri, 22 Dec 2000 08:39:09 -0800
Received: from [202.106.185.116] ([202.106.185.116]:25285 "HELO smtp2.yeah.net")
	by oss.sgi.com with SMTP id <S553711AbQLVQil>;
	Fri, 22 Dec 2000 08:38:41 -0800
Received: from public (unknown [61.130.47.96])
	by smtp2.yeah.net (Postfix) with SMTP id C80541C506062
	for <netdev@oss.sgi.com>; Sat, 23 Dec 2000 00:40:17 +0800 (CST)
Date:   Sat, 23 Dec 2000 0:39:18 +0800
From:   Tech Support <jxbmail@yeah.net>
Reply-To: jxbmail@yeah.net
To:     netdev@oss.sgi.com <netdev@oss.sgi.com>
Subject: ppp device over pppoe datalink
X-mailer: FoxMail 3.1 beta [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
Message-Id: <20001222164017.C80541C506062@smtp2.yeah.net>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Dear sir,

      Merry Christmas and have a very nice new year!


      I've a question to ask you,

      (1)I'm programming a ppp windows client,from windows ppp client
      to linux ppp server,
      
      (2)when complete lcp,pap/chap,ipcp section,ppp server will
      assign me a IP address,

      (3)How do I write this IP address to my route table,and how
      my windows OS can communication with internet via PPP Server
      gateway? 
         Need to build any ppp device for windows upon this new
      route table?


       I'm looking forward for your feedback!


       Thank you!
       Best regards,
       Jiang XiaoBing
       yh@mail.huptt.zj.cn



From owner-netdev@oss.sgi.com Fri Dec 22 15:13:02 2000
Received:  by oss.sgi.com id <S553747AbQLVXMm>;
	Fri, 22 Dec 2000 15:12:42 -0800
Received: from kogge.hanse.de ([192.76.134.17]:5380 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S553704AbQLVXMQ>;
	Fri, 22 Dec 2000 15:12:16 -0800
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id AAA69396;
	Sat, 23 Dec 2000 00:12:02 +0100 (CET)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id AAA19224;
	Sat, 23 Dec 2000 00:02:49 +0100
Date:   Sat, 23 Dec 2000 00:02:49 +0100
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200012222302.AAA19224@baty.hanse.de>
To:     davem@redhat.com
CC:     netdev@oss.sgi.com
In-reply-to: <200012201820.KAA10981@pizda.ninka.net> (davem@redhat.com)
Subject: Re: lapb module irq context problems
References: <200012192332.AAA11827@baty.hanse.de> <200012201820.KAA10981@pizda.ninka.net>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "David" == David S Miller <davem@redhat.com> writes:

    David> I would recommend to do #3 but make it identical to
    David> lapb_data_received() except that it explicitly uses
    David> kfree_skb_irq().  Let the core networking "defer to

Yes. My idea of #3 b was that lapb_data_received_irq() is of equal type
as lapb_data_received(). lapb_data_received_irq() would just call
netif_rx() on a special `lapb_irq' pseudo device, and a special packet
handler would receive all these packet and just pass them to the
current lapb_data_received().

Code which already calls lapb_data_received() from soft irq does not need
to be changed. Only code that currently calls lapb_data_received()
from hard irq needs to be changed to use the new lapb_data_received_irq()
interface. The output related interface to the lapb module is usually
called on behalf of dev->hard_start_xmit (which is already soft irq context).
The same hold for the timer events.

Thus, once the `hard irq' drivers are converted to the new interface,
there will no longer be any part in the lapb protocol engine that is
called from hard irq. Thus, no `kfree_skb()' needs to be changed
to `kree_skb_irq()'. And code which already uses the lapb module
from soft irq will not be penalized by the additional kfree_skb_any()
overhead.

As the input path of the lapb protocol is not trivial (it could even
trigger additional output to acknowledge the revied frame), moving
the whole protocol processing from hard irq to soft irq might be a
good idea anyway.

Henner




From owner-netdev@oss.sgi.com Fri Dec 22 15:17:03 2000
Received:  by oss.sgi.com id <S553755AbQLVXQm>;
	Fri, 22 Dec 2000 15:16:42 -0800
Received: from pizda.ninka.net ([216.101.162.242]:17280 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S553746AbQLVXQj>;
	Fri, 22 Dec 2000 15:16:39 -0800
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id PAA01256;
	Fri, 22 Dec 2000 15:00:09 -0800
Date:   Fri, 22 Dec 2000 15:00:09 -0800
Message-Id: <200012222300.PAA01256@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     eis@baty.hanse.de
CC:     netdev@oss.sgi.com
In-reply-to: <200012222302.AAA19224@baty.hanse.de> (message from Henner Eisen
	on Sat, 23 Dec 2000 00:02:49 +0100)
Subject: Re: lapb module irq context problems
References: <200012192332.AAA11827@baty.hanse.de> <200012201820.KAA10981@pizda.ninka.net> <200012222302.AAA19224@baty.hanse.de>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date: Sat, 23 Dec 2000 00:02:49 +0100
   From: Henner Eisen <eis@baty.hanse.de>

   As the input path of the lapb protocol is not trivial (it could
   even trigger additional output to acknowledge the revied frame),
   moving the whole protocol processing from hard irq to soft irq
   might be a good idea anyway.

Moving all packet work out of hardirq certainly simplified ipv4
greatly, which is as complex as any :-)

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Fri Dec 22 22:36:06 2000
Received:  by oss.sgi.com id <S553765AbQLWGfr>;
	Fri, 22 Dec 2000 22:35:47 -0800
Received: from horus.its.uow.edu.au ([130.130.68.25]:24009 "EHLO
        horus.its.uow.edu.au") by oss.sgi.com with ESMTP id <S553759AbQLWGfZ>;
	Fri, 22 Dec 2000 22:35:25 -0800
Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12])
	by horus.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id RAA01619;
	Sat, 23 Dec 2000 17:35:11 +1100 (EST)
Message-ID: <3A4448DE.DEE4C43C@uow.edu.au>
Date:   Sat, 23 Dec 2000 17:40:30 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: netdevice interface changes in 2.4.0test13pre4ac1
References: <E149VsK-0004w2-00@the-village.bc.nu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Alan Cox wrote:
> ...
> 
> 2.4.0test13pre4-ac1
> ...
> o       Fix network register/hotplug/publish problems   (Andrew Morton)

This patch is a step on the way to changing how netdevices are
registered.  It is a significant restructuring which was
basically forced upon us by a bad race condition which the new
hotplug code exposed.  

Alan has applied the core netdevice patch and a set of changes
to the tokenring drivers which make them use the new interface.

There are about eighty drivers which still need to be changed and
I'll be doing these in large lumps.  fc, hippi, ethernet, etc.

I'm determined to get them *all* done, and quickly.  We cannot
just half-do it and leave another back-compatibility layer in
the kernel.

If anyone wants to help (please) then please send the patches
to me so I can maintain them in nice big, orthogonal
easily-backed-out-if-necessary chunks.  Thanks.

Here's a description of the problem, and the interface
changes which were made to address it:




Proposed 2.4 netdevice interface change.
Andrew Morton <andrewm@uow.edu.au>
19 December 2000


     The problem
     ===========

A typical netdevice's probe() function is structured like this:

	int xxx_probe()
	{
		struct net_device *dev = init_etherdev();
		...
		initialise()
		...
		dev->open = xxx_open;
		if (errcode)
			unregister_netdevice(dev);
		return errcode;
	}

The problem is, init_etherdev() calls register_netdevice() and makes
the netdevice available in the kernel namespace before it's ready to be
opened.  Probe routines can easily take tens of milliseconds talking to
slow EEPROMs and MII devices so the window is large.

The problem becomes acute now we are running /sbin/hotplug from within
register_netdevice().  When /sbin/hotplug tries to open the device it
wins the race every time! The device's `open' method is NULL and the
open "succeeds", but the hardware wasn't prepared for operation.  Bad.

Kernel 2.4.0-test12 has a kludge in it (dev_probe_lock) which protects
PCI devices, but that's not a fix.

The big kernel lock accidentally protects us from this race because
it's taken by both sys_init_module() and sys_ioctl().  But if the
probe() routines calls schedule() - and they all can - the BKL is
dropped and we lose.


"Old style" netdevices which statically allocate their struct
net_device are OK.  They do this:

	static struct net_device yyy_dev;

	init_module()
	{
		yyy_dev.init = yyy_probe;
		register_netdev(&yyy_dev);
	}

This works fine because register_netdevice() calls yyy_probe() prior to
registering the device, and register_netdevice() calls /sbin/hotplug
_after_ the call to yyy_probe() and after registering the netdevice.


The tokenring, hippi and fc drivers do quite wierd things in their
initialisation.  This is not described here, but suffice to say that they
are racy and they can be fixed with the proposed new design.



     The fix
     =======

The correct fix is to:

     1): Not make the netdevice visible in the namespace until
         it's ready to accept open()s.

     2): Allocate the netdevice's name ("eth0") early in
         probe(), because drivers like to print it out in diagnostic
         messages.

     2): Not call /sbin/hotplug until the device is registered
         and ready to accept open()s.

     3):  Minimise the amount of changes which are required.

     4): Not break the "Old style" drivers.

     5): Provide easy 2.2 back-compatibility for those drivers
         which support 2.2.

     6): Change ALL the drivers quickly! Don't leave yet
         another back-compatibility layer lying around.

     7): Support a back-compatibility for the duration of the
         netdevice changes.  Perhaps a couple of weeks.

     8): Approximately 83 drivers need to be changed.

     The new interface
     =================

Netdevices gain a new state called "hidden".  A hidden netdevice is not
visible in namespace lookups, but its existence reserves the interface
name to prevent duplicates or races.


We create three new API functions:

     prepare_etherdev(), prepare_trdev(), prepare_fcdev(), etc.

          These are similar to init_etherdev() and friends,
          but the device is created in a hidden state and protocols are
          not notified of the device's existence and /sbin/hotplug is
          not called.

     publish_netdev(struct net_device *dev)

          This is a new API function altogether.  It takes a
          hidden netdevice and "commits" it.  The netdevice is
          unhidden, the protocols are notified of its existence and
          /sbin/hotplug is called.

     withdraw_netdev(struct net_device *dev)

          This reverts the effects of prepare_etherdev() and
          friends.  It's called on the error path and it simply removes
          the hidden netdevice from the device list.  Protocols are not
          notified and /sbin/hotplug is not called.


We retain these:

     register_netdev()

          This function remains in place.  It should only be
          used by "old style" drivers and by virtual devices such as
          the IP/IP driver and the bonding driver.

          register_netdev() registers the device in the
          namespace (unhidden), notifies protocols and runs
          /sbin/hotplug.

     register_netdevice()

          Lower-level form of register_netdev().  The device
          is registered in the namespace and the protocols are
          notified.  /sbin/hotplug is not called.

          This function must be called with the rtnl_lock
          held.  It is typically used by virtual devices such as
          tunnelling protocols and bonding drivers.

          So there is no hotplug notification when one of
          these devices is registered.  Should there be? If so, they
          should use register_netdev().

     unregister_netdev()

          This function remains in place.  Should only be
          called for an unhidden interface.  It closes the device,
          removes the interface from the namespace, notifies protocols
          of the disappearing interface and then calls /sbin/hotplug.

     unregister_netdevice()

          Lower-level form of unregister_netdev().  The
          device is unregistered and then the protocols are notified,
          but /sbin/hotplug is not called.


Additional details on these functions are available in the source in
kernel-doc format.

Note that /sbin/hotplug is never called under the rtnl_lock.  This is
not very important at the time of writing, because /sbin/hotplug is
launched asynchronously.  But it leaves open the option of running
/sbin/hotplug synchronously at some time in the future, which would be
nice.


Doomed functions:

     init_etherdev(), init_trdev(), etc.

          These will remain in existence until all drivers
          are changed.  They will still have the raciness identified
          above.

          They register the device in the namespace
          (unhidden) and notify protocols.  But /sbin/hotplug is NOT
          run for these devices.

          /sbin/hotplug WILL be called when these devices are
          unregistered, however.


Other things:

     #define HAVE_PUBLISH_NETDEV

          This is for 2.2-compatible drivers.  They can do this:

          #ifdef HAVE_PUBLISH_NETDEV
          #define init_etherdev prepare_etherdev
          #define publish_netdev(dev) do {} while (0)
          #define withdraw_netdev unregister_netdev
          #endif

New driver structure:

	int xxx_probe()
	{
-		struct net_device *dev = init_etherdev();
+		struct net_device *dev = prepare_etherdev();
		...
		initialise()
		...
		dev->open = xxx_open;
		if (errcode)
-			unregister_netdevice(dev);
+			withdraw_netdevice(dev);
+		else
+			publish_netdev(dev);
		return errcode;
	}

In other words:

	int xxx_probe()
	{
		struct net_device *dev = prepare_etherdev();
		...
		initialise()
		...
		dev->open = xxx_open;
		if (errcode)
			withdraw_netdevice(dev);
		else
			publish_netdev(dev);
		return errcode;
	}

From owner-netdev@oss.sgi.com Sat Dec 23 04:54:40 2000
Received:  by oss.sgi.com id <S553780AbQLWMyU>;
	Sat, 23 Dec 2000 04:54:20 -0800
Received: from isis.its.uow.edu.au ([130.130.68.21]:7104 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S553760AbQLWMxv>;
	Sat, 23 Dec 2000 04:53:51 -0800
Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12])
	by isis.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id XAA26363;
	Sat, 23 Dec 2000 23:53:05 +1100 (EST)
Message-ID: <3A44A170.4D864E7F@uow.edu.au>
Date:   Sat, 23 Dec 2000 23:58:24 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>,
        "David S. Miller" <davem@redhat.com>, stefani@lkg.dec.com,
        lkml <linux-kernel@vger.kernel.org>, netdev@oss.sgi.com
Subject: [patch] remove init_fddidev
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This was pretty simple.  Also did the SET_MODULE_OWNER thing.

It affects two files:

drivers/net/defxx.c
drivers/net/ptifddi.c

I'm not sure what the story is with ptifddi.c.  It isn't
mentioned in any of the kernel Makefiles?

Now just 67 ethernet drivers to do :)


--- linux-2.4.0-test13pre4-ac2/drivers/net/defxx.c	Sat Sep  9 16:19:26 2000
+++ linux-akpm/drivers/net/defxx.c	Sat Dec 23 23:48:35 2000
@@ -423,15 +423,17 @@
 	}
 
 	/*
-	 * init_fddidev() allocates a device structure with private data, clears the device structure and private data,
-	 * and  calls fddi_setup() and register_netdev(). Not much left to do for us here.
+	 * prepare_fddidev() allocates a device structure with private data, clears the device
+	 * structure and private data and then calls fddi_setup().  Once the device is ready
+	 * to be opened we call publish_netdev() to advertise its availability.
 	 */
-	dev = init_fddidev( NULL, sizeof(*bp));
+	dev = prepare_fddidev(NULL, sizeof(*bp));
 
 	if (!dev) {
 		printk (KERN_ERR "defxx: unable to allocate fddidev, aborting\n");
 		return -ENOMEM;
 	}
+	SET_MODULE_OWNER(dev);
 
 	bp = (DFX_board_t*)dev->priv;
 
@@ -470,12 +472,13 @@
 	if (dfx_driver_init(dev) != DFX_K_SUCCESS)
 		goto err_out_region;
 
+	publish_netdev(dev);
 	return 0;
 
 err_out_region:
 	release_region(ioaddr, pdev ? PFI_K_CSR_IO_LEN : PI_ESIC_K_CSR_IO_LEN);
 err_out:
-	unregister_netdev(dev);
+	withdraw_netdev(dev);
 	kfree(dev);
 	return -ENODEV;
 }
@@ -1187,14 +1190,11 @@
 
 	DBG_printk("In dfx_open...\n");
 	
-	MOD_INC_USE_COUNT;
-
 	/* Register IRQ - support shared interrupts by passing device ptr */
 
 	if (request_irq(dev->irq, (void *)dfx_interrupt, SA_SHIRQ, dev->name, dev))
 	{
 		printk(KERN_ERR "%s: Requested IRQ %d is busy\n", dev->name, dev->irq);
-		MOD_DEC_USE_COUNT;
 		return -EAGAIN;
 	}
 
@@ -1232,7 +1232,6 @@
 	{
 		printk(KERN_ERR "%s: Adapter open failed!\n", dev->name);
 		free_irq(dev->irq, dev);
-		MOD_DEC_USE_COUNT;
 		return -EAGAIN;
 	}
 
@@ -1326,7 +1325,6 @@
 
 	free_irq(dev->irq, dev);
 	
-	MOD_DEC_USE_COUNT;
 	return(0);
 }
 
--- linux-2.4.0-test13pre4-ac2/drivers/net/ptifddi.c	Sat Jul 15 19:36:08 2000
+++ linux-akpm/drivers/net/ptifddi.c	Sat Dec 23 23:49:09 2000
@@ -154,18 +154,23 @@
 	static unsigned version_printed = 0;
 	struct ptifddi *pp;
 	int i;
-
-	dev = init_fddidev(0, sizeof(struct ptifddi));
+	int retval;
 
 	if(version_printed++ == 0)
 		printk(version);
 
+	dev = prepare_fddidev(0, sizeof(struct ptifddi));
+	if (dev == NULL)
+		return -ENOMEM;
+	SET_MODULE_OWNER(dev);
+
 	/* Register 0 mapping contains DPRAM. */
 	pp->dpram = (struct dfddi_ram *) sbus_ioremap(
 	    &sdep->resource[0], 0, sizeof(sturct dfddi_ram), "PTI FDDI DPRAM");
 	if(!pp->dpram) {
 		printk("ptiFDDI: Cannot map DPRAM I/O area.\n");
-		return -ENODEV;
+		retval = -ENODEV;
+		goto err_out;
 	}
 
 	/* Next, register 1 contains reset byte. */
@@ -173,7 +178,8 @@
 	    &sdep->resource[1], 0, 1, "PTI FDDI RESET Byte");
 	if(!pp->reset) {
 		printk("ptiFDDI: Cannot map RESET byte.\n");
-		return -ENODEV;
+		retval = -ENODEV;
+		goto err_out;
 	}
 
 	/* Register 2 contains unreset byte. */
@@ -181,7 +187,8 @@
 	    &sdep->resource[2], 0, 1, "PTI FDDI UNRESET Byte");
 	if(!pp->unreset) {
 		printk("ptiFDDI: Cannot map UNRESET byte.\n");
-		return -ENODEV;
+		retval = -ENODEV;
+		goto err_out;
 	}
 
 	/* Reset the card. */
@@ -191,7 +198,8 @@
 	i = pti_card_test(pp);
 	if(i) {
 		printk("ptiFDDI: Bootup card test fails.\n");
-		return -ENODEV;
+		retval = -ENODEV;
+		goto err_out;
 	}
 
 	/* Clear DPRAM, start afresh. */
@@ -202,6 +210,12 @@
 
 	/* Now load main card FDDI firmware, using the loader. */
 	pti_load_main_firmware(pp);
+	publish_netdev(dev);
+	return 0;
+err_out:
+	withdraw_netdev(dev);
+	kfree(dev);
+	return retval;
 }
 
 int __init ptifddi_sbus_probe(struct net_device *dev)

From owner-netdev@oss.sgi.com Sat Dec 23 04:54:50 2000
Received:  by oss.sgi.com id <S553782AbQLWMyk>;
	Sat, 23 Dec 2000 04:54:40 -0800
Received: from isis.its.uow.edu.au ([130.130.68.21]:19392 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S553772AbQLWMyW>;
	Sat, 23 Dec 2000 04:54:22 -0800
Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12])
	by isis.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id XAA26216;
	Sat, 23 Dec 2000 23:51:34 +1100 (EST)
Message-ID: <3A44A114.2A277D95@uow.edu.au>
Date:   Sat, 23 Dec 2000 23:56:52 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>
CC:     vmabraham@hotmail.com, Steve.Ralston@lsil.com,
        Auvo.Hakkinen@cs.Helsinki.FI, Juha.Sievanen@cs.Helsinki.FI,
        Taneli.Vahakangas@cs.Helsinki.FI, deepak@plexity.net,
        lkml <linux-kernel@vger.kernel.org>, netdev@oss.sgi.com
Subject: [patch] remove init_fcdev
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Alan,

the patch removes use of the unsafe init_fcdev() and replaces it with
the new prepare_fcdev()/publish_netdev() API as described at

	http://www.uow.edu.au/~andrewm/linux/netdevice2.txt

I changed drivers/i2o/i2o_lan.c:i2o_lan_register_device() to use prepare_fddidev().  Not sure why it wasn't using init_fddidev()
initially?

I also migrated a couple of these drivers over to use
SET_MODULE_OWNER.

Files affected:

drivers/net/fc/iph5526.c
drivers/block/fusion/mptlan.c
drivers/i2o/i2o_lan.c

This all went in pretty cleanly.

A patch for rrunner.c has been sent to Jes so init_hippi_dev() is
done too.



--- linux-2.4.0-test13pre4-ac2/drivers/net/fc/iph5526.c	Sat Dec 23 17:24:20 2000
+++ linux-akpm/drivers/net/fc/iph5526.c	Sat Dec 23 22:02:21 2000
@@ -25,6 +25,7 @@
 07.07.99 Can be loaded as part of the Kernel. Changed semaphores. Added
          more checks before invalidating SEST entries.
 07.08.99 Added Broadcast IP stuff and fixed an unicast timeout bug.
+23Dec00  Use new publish_netdev interface.  Use SET_MODULE_OWNER. (andrewm@uow.edu.au)
 ***********************************************************************/
 /* TODO:
 	R_T_TOV set to 15msec in Loop topology. Need to be 100 msec.
@@ -33,7 +34,7 @@
 */	
 
 static const char *version =
-    "iph5526.c:v1.0 07.08.99 Vineet Abraham (vmabraham@hotmail.com)\n";
+    "iph5526.c:v1.0 23Dec00 Vineet Abraham (vmabraham@hotmail.com)\n";
 
 #include <linux/module.h>
 #include <linux/kernel.h>
@@ -245,7 +246,7 @@
  
 	if(fc[count] != NULL) {
 		if (dev == NULL) {
-			dev = init_fcdev(NULL, 0);
+			dev = prepare_fcdev(NULL, 0);
 			if (dev == NULL)
 				return -ENOMEM;
 		}
@@ -266,6 +267,7 @@
 		dev->dev_addr[4] = (fi->g.my_port_name_low & 0x0000FF00) >> 8;
 		dev->dev_addr[5] = fi->g.my_port_name_low;
 #ifndef MODULE
+		publish_netdev(dev);
 		count++;
 	}
 	else
@@ -2916,14 +2918,12 @@
 static int iph5526_open(struct net_device *dev)
 {
 	netif_start_queue(dev);
-	MOD_INC_USE_COUNT;
 	return 0;
 }
 
 static int iph5526_close(struct net_device *dev)
 {
 	netif_stop_queue(dev);
-	MOD_DEC_USE_COUNT;
 	return 0;
 }
 
@@ -4543,7 +4543,7 @@
 
 	while(fc[i] != NULL) {
 		dev_fc[i] = NULL;
-		dev_fc[i] = init_fcdev(dev_fc[i], 0);	
+		dev_fc[i] = prepare_fcdev(dev_fc[i], 0);	
 		if (dev_fc[i] == NULL) {
 			printk("iph5526.c: init_fcdev failed for card #%d\n", i+1);
 			break;
@@ -4551,16 +4551,20 @@
 		dev_fc[i]->irq = irq;
 		dev_fc[i]->mem_end = bad;
 		dev_fc[i]->base_addr = io;
-		dev_fc[i]->init = iph5526_probe;
+//		dev_fc[i]->init = iph5526_probe;
 		dev_fc[i]->priv = fc[i];
 		fc[i]->dev = dev_fc[i];
-		if (register_fcdev(dev_fc[i]) != 0) {
+		if (iph5526_probe(dev_fc[i]) != 0) {
+			withdraw_netdev(dev_fc[i]);
 			kfree(dev_fc[i]);
 			dev_fc[i] = NULL;
 			if (i == 0) {
 				printk("iph5526.c: IP registeration failed!!!\n");
 				return -ENODEV;
 			}
+		} else {
+			SET_MODULE_OWNER(dev_fc[i]);
+			publish_netdev(dev_fc[i]);
 		}
 		i++;
 	}
@@ -4578,7 +4582,7 @@
 	void *priv = dev->priv;
 		fc[i]->g.dont_init = TRUE;
 		take_tachyon_offline(fc[i]);
-		unregister_fcdev(dev);
+		unregister_netdev(dev);
 		clean_up_memory(fc[i]);
 		if (dev->priv)
 			kfree(priv);
--- linux-2.4.0-test13pre4-ac2/drivers/block/fusion/mptlan.c	Sat Dec 23 17:24:19 2000
+++ linux-akpm/drivers/block/fusion/mptlan.c	Sat Dec 23 22:02:21 2000
@@ -1306,7 +1306,7 @@
 	struct mpt_lan_priv *priv = NULL;
 	u8 HWaddr[FC_ALEN], *a;
 
-	dev = init_fcdev(NULL, sizeof(struct mpt_lan_priv));
+	dev = prepare_fcdev(NULL, sizeof(struct mpt_lan_priv));
 	if (!dev)
 		return (NULL);
 	dev->mtu = MPT_LAN_MTU;
@@ -1378,7 +1378,8 @@
 		"and setting initial values\n"));
 
 	SET_MODULE_OWNER(dev);
-	
+	publish_netdev(dev);
+
 	return dev;
 }
 
@@ -1460,7 +1461,7 @@
 
 		printk (KERN_INFO MYNAM ": %s/%s: Fusion MPT LAN device unregistered.\n",
 			       IOC_AND_NETDEV_NAMES_s_s(dev));
-		unregister_fcdev(dev);
+		unregister_netdev(dev);
 		mpt_landev[i] = (struct net_device *) 0xdeadbeef; /* Debug */
 	}
 
--- linux-2.4.0-test13pre4-ac2/drivers/i2o/i2o_lan.c	Sat Dec 23 17:24:20 2000
+++ linux-akpm/drivers/i2o/i2o_lan.c	Sat Dec 23 22:28:37 2000
@@ -744,11 +744,8 @@
 	struct i2o_controller *iop = i2o_dev->controller;
 	u32 mc_addr_group[64];
 
-	MOD_INC_USE_COUNT;
-
 	if (i2o_claim_device(i2o_dev, &i2o_lan_handler)) {
 		printk(KERN_WARNING "%s: Unable to claim the I2O LAN device.\n", dev->name);
-		MOD_DEC_USE_COUNT;
 		return -EAGAIN;
 	}
 	dprintk(KERN_INFO "%s: I2O LAN device (tid=%d) claimed by LAN OSM.\n",
@@ -765,7 +762,6 @@
 	if (i2o_query_scalar(iop, i2o_dev->lct_data.tid, 0x0001, -1,
 			     &mc_addr_group, sizeof(mc_addr_group)) < 0 ) {
 		printk(KERN_WARNING "%s: Unable to query LAN_MAC_ADDRESS group.\n", dev->name);
-		MOD_DEC_USE_COUNT;
 		return -EAGAIN;
 	}
 	priv->max_size_mc_table = mc_addr_group[8];
@@ -775,7 +771,6 @@
 	priv->i2o_fbl = kmalloc(priv->max_buckets_out * sizeof(struct sk_buff *),
 				GFP_KERNEL);
 	if (priv->i2o_fbl == NULL) {
-		MOD_DEC_USE_COUNT;
 		return -ENOMEM;
 	}
 	priv->i2o_fbl_tail = -1;
@@ -818,8 +813,6 @@
 		ret = -EBUSY;
 	}
 
-	MOD_DEC_USE_COUNT;
-
 	return ret;
 }
 
@@ -1281,15 +1274,13 @@
 	u8 hw_addr[8];
 	u32 tx_max_out = 0;
 	unsigned short (*type_trans)(struct sk_buff *, struct net_device *);
-	void (*unregister_dev)(struct net_device *dev);
 
 	switch (i2o_dev->lct_data.sub_class) {
 	case I2O_LAN_ETHERNET:
-		dev = init_etherdev(NULL, sizeof(struct i2o_lan_local));
+		dev = prepare_etherdev(NULL, sizeof(struct i2o_lan_local));
 		if (dev == NULL)
 			return NULL;
 		type_trans = eth_type_trans;
-		unregister_dev = unregister_netdev;
 		break;
 
 #ifdef CONFIG_ANYLAN
@@ -1304,40 +1295,25 @@
 		dev = prepare_trdev(NULL, sizeof(struct i2o_lan_local));
 		if (dev==NULL)
 			return NULL;
-		publish_netdev(dev);		/* AKPM: racy */
 		type_trans = tr_type_trans;
-		unregister_dev = unregister_netdev;
 		break;
 #endif
 
 #ifdef CONFIG_FDDI
 	case I2O_LAN_FDDI:
 	{
-		int size = sizeof(struct net_device) + sizeof(struct i2o_lan_local);
-
-		dev = (struct net_device *) kmalloc(size, GFP_KERNEL);
+		dev = prepare_fddidev(NULL, sizeof(struct i2o_lan_local));
 		if (dev == NULL)
 			return NULL;
-		memset((char *)dev, 0, size);
-	    	dev->priv = (void *)(dev + 1);
-
-		if (dev_alloc_name(dev, "fddi%d") < 0) {
-			printk(KERN_WARNING "i2o_lan: Too many FDDI devices.\n");
-			kfree(dev);
-			return NULL;
-		}
 		type_trans = fddi_type_trans;
-		unregister_dev = (void *)unregister_netdev;
-
 		fddi_setup(dev);
-		register_netdev(dev);
 	}
 	break;
 #endif
 
 #ifdef CONFIG_NET_FC
 	case I2O_LAN_FIBRE_CHANNEL:
-		dev = init_fcdev(NULL, sizeof(struct i2o_lan_local));
+		dev = prepare_fcdev(NULL, sizeof(struct i2o_lan_local));
 		if (dev == NULL)
 			return NULL;
 		type_trans = NULL;
@@ -1345,7 +1321,6 @@
  * and export it in include/linux/fcdevice.h
  *		type_trans = fc_type_trans;
  */
-		unregister_dev = (void *)unregister_fcdev;
 		break;
 #endif
 
@@ -1382,7 +1357,7 @@
 			     0x0001, 0, &hw_addr, sizeof(hw_addr)) < 0) {
 		printk(KERN_ERR "%s: Unable to query hardware address.\n", dev->name);
 		unit--;
-		unregister_dev(dev);
+		withdraw_netdev(dev);
 		kfree(dev);
 		return NULL;
 	}
@@ -1397,7 +1372,7 @@
 			     0x0007, 2, &tx_max_out, sizeof(tx_max_out)) < 0) {
 		printk(KERN_ERR "%s: Unable to query max TX queue.\n", dev->name);
 		unit--;
-		unregister_dev(dev);
+		withdraw_netdev(dev);
 		kfree(dev);
 		return NULL;
 	}
@@ -1428,6 +1403,8 @@
 	if (i2o_dev->lct_data.sub_class == I2O_LAN_ETHERNET)
 		dev->change_mtu	= i2o_lan_change_mtu;
 
+	SET_MODULE_OWNER(dev);
+	publish_netdev(dev);
 	return dev;
 }
 
@@ -1533,7 +1510,7 @@
 			break;
 #ifdef CONFIG_FDDI
 		case I2O_LAN_FDDI:
-			unregister_netdevice(dev);
+			unregister_netdev(dev);
 			break;
 #endif
 #ifdef CONFIG_TR
@@ -1543,7 +1520,7 @@
 #endif
 #ifdef CONFIG_NET_FC
 		case I2O_LAN_FIBRE_CHANNEL:
-			unregister_fcdev(dev);
+			unregister_netdev(dev);
 			break;
 #endif
 		default:

From owner-netdev@oss.sgi.com Sat Dec 23 07:01:30 2000
Received:  by oss.sgi.com id <S553787AbQLWPBU>;
	Sat, 23 Dec 2000 07:01:20 -0800
Received: from isis.its.uow.edu.au ([130.130.68.21]:38796 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S553772AbQLWPBH>;
	Sat, 23 Dec 2000 07:01:07 -0800
Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12])
	by isis.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id CAA28787;
	Sun, 24 Dec 2000 02:00:41 +1100 (EST)
Message-ID: <3A44BF57.B01C2097@uow.edu.au>
Date:   Sun, 24 Dec 2000 02:05:59 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Manfred <manfred@colorfullife.com>
CC:     linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: Q: netdevice interface change
References: <3A44B324.1E1E9AF1@colorfullife.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Manfred wrote:
> 
> Hi Andrew,
> 
> I have 2 questions about your netdevice2.txt:
>    http://www.uow.edu.au/~andrewm/linux/netdevice2.txt
> 
> * is withdraw_netdevice() really required, can't unregister_netdev
> check "hidden", and notify the protocols/hotplug based on that value?

Yes, it's basically the same thing and yes, it could be done
this way.  The only difference is that withdraw_netdev()
will blurt out a warning if it is called on an unhidden device.
This is useful now, but less so later.   I guess it could be
#defined onto unregister_netdev later..


> * I don't like the backward compatibility section:
> 
> <<<<<<<<
> Other things:
> 
>      #define HAVE_PUBLISH_NETDEV
> 
>           This is for 2.2-compatible drivers.  They can do this:
> 
>           #ifdef HAVE_PUBLISH_NETDEV
>           #define init_etherdev prepare_etherdev
>           #define publish_netdev(dev) do {} while (0)
>           #define withdraw_netdev unregister_netdev
>           #endif
> >>>>>>>>
> 
> As far as I know Linus prefers backward compatibility the other way
> around:
> 
> <<<<<<
> A 2.4 driver that must remain compatible with 2.2 should use
> the new interface and add these lines to their source file:
> 
>        #ifndef HAVE_PUBLISH_NETDEV
>        #define prepare_etherdev init_etherdev
>        #define publish_netdev(dev) do {} while (0)
>        #define withdraw_netdev unregister_netdev
>        #endif
> >>>>>>

You are correct, and that is in fact how I did it in rrunner.c.
I'll do eepro100 and acenic that way too.  The manual is wrong :)

BTW: I just finished the ethernet devices, so my request for
help can be ignored.  Fixed a truckload of unchecked kmallocs
and error-path memory leaks while I was at it.  Sigh.

-

From owner-netdev@oss.sgi.com Sat Dec 23 13:11:16 2000
Received:  by oss.sgi.com id <S553786AbQLWVK4>;
	Sat, 23 Dec 2000 13:10:56 -0800
Received: from brutus.conectiva.com.br ([200.250.58.146]:33018 "EHLO
        dhcp046.distro.conectiva") by oss.sgi.com with ESMTP
	id <S553695AbQLWVKv>; Sat, 23 Dec 2000 13:10:51 -0800
Received: (ralf@lappi) by bacchus.dhis.org id <S868135AbQLWVDb>;
	Sat, 23 Dec 2000 19:03:31 -0200
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id RAA22718
	for <ralf@uni-koblenz.de>; Fri, 22 Dec 2000 17:39:09 +0100 (MET)
Received: from [202.106.185.116] ([202.106.185.116]:27589 "HELO smtp2.yeah.net")
	by oss.sgi.com with SMTP id <S553735AbQLVQiv>;
	Fri, 22 Dec 2000 08:38:51 -0800
Received: from public (unknown [61.130.47.96])
	by smtp2.yeah.net (Postfix) with SMTP id 52DEA1C506062
	for <owner-netdev@oss.sgi.com>; Sat, 23 Dec 2000 00:40:25 +0800 (CST)
Date:	Sat, 23 Dec 2000 0:39:25 +0800
From:	Tech Support <jxbmail@yeah.net>
Reply-To: jxbmail@yeah.net
To:	"owner-netdev@oss.sgi.com" <owner-netdev@oss.sgi.com>
Subject: ppp device over pppoe datalink
X-mailer: FoxMail 3.1 beta [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
Message-Id: <20001222164025.52DEA1C506062@smtp2.yeah.net>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Dear sir,

      Merry Christmas and have a very nice new year!


      I've a question to ask you,

      (1)I'm programming a ppp windows client,from windows ppp client
      to linux ppp server,
      
      (2)when complete lcp,pap/chap,ipcp section,ppp server will
      assign me a IP address,

      (3)How do I write this IP address to my route table,and how
      my windows OS can communication with internet via PPP Server
      gateway? 
         Need to build any ppp device for windows upon this new
      route table?


       I'm looking forward for your feedback!


       Thank you!
       Best regards,
       Jiang XiaoBing
       yh@mail.huptt.zj.cn


From owner-netdev@oss.sgi.com Sat Dec 23 20:19:38 2000
Received:  by oss.sgi.com id <S553789AbQLXETS>;
	Sat, 23 Dec 2000 20:19:18 -0800
Received: from isis.its.uow.edu.au ([130.130.68.21]:29948 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S553724AbQLXESz>;
	Sat, 23 Dec 2000 20:18:55 -0800
Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12])
	by isis.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id PAA01063;
	Sun, 24 Dec 2000 15:16:39 +1100 (EST)
Message-ID: <3A4579E6.6BABBDD7@uow.edu.au>
Date:   Sun, 24 Dec 2000 15:21:58 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Gerrit Huizenga <gerrit@us.ibm.com>
CC:     timw@splhi.com, Andi Kleen <ak@suse.de>,
        Tim Hockin <thockin@cobalt.com>, npollitt@sgi.com,
        lse-tech@lists.sourceforge.net, slinx@engr.sgi.com,
        netdev@oss.sgi.com
Subject: Re: [Lse-tech] fwd: Process Pinning
References: Your message of Thu, 21 Dec 2000 16:48:48 PST. <20001221164848.A1091@scutter.internal.splhi.com> <200012230052.eBN0q6E07065@eng2.sequent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Gerrit Huizenga wrote:
> 
> Andi Kleen wrote:
> 
> > You think it wouldn't help for database servers ?  (e.g. with a NIC and a
> > SCSI controller per CPU)
> >
> > -Andi
> 
> I think NIC to CPU binding would simply increase the latency problem
> for interrupt delivery in this case.  Allowing the APIC to direct an
> interrupt to the first available CPU decreases the average interrupt
> delivery latency.  And, I'd guess that the interrupt latency more
> likely governs the throughput than the sharing of a few cache lines ( 1
> / nprocessors) of the time on most modern SMP systems.
> 
> Of course, this depends a lot on how long a lock is held (lock_irq()).
> I had heard that the number of instructions generally that a lock
> was held in Linux was *very* small, although some code I've looked
> at doesn't seem to bear that out (at least not any more).
> 


I had a few wild thoughts on this topic earlier in the year.  I haven't
had a chance to do anything with them because people keep on putting
bugs in the kernel :)

* presume that interrupts are wickedly expensive and we want to
  minimise them.  This is more relevant to low-end (100mbit) NICs.

* presume that cross-CPU traffic and cache misses are expensive, and
  we want to optimise for these.

Some avenues for investigation:

* Disable the NIC's interrupts at the hardware level when we're doing
  receive processing.

  This would be a big performance win on uniprocessor - there's no
  *point* in taking the Rx interrupt when we're doing protocol
  processing - we're just going to queue the packet and go back to
  protocol processing.

  I think it's also a performance win on SMP.  If we're using
  NIC->CPU bonding then it's basically a UP problem anyway.

  So it's better to disable the Rx interrupts at the end of the Rx
  ISR if we have sent something to netif_rx().  At the end of
  net_rx_action() processing we call back into the driver to see if it
  has more Rx frames available.  If there are, well, we just process
  them as well, still with hardware interrupts disabled.  This is
  super-quick.  If there aren't any Rx packets available, turn on
  Rx interrupts.

  Note that this magically fixes the SMP packets-out-of-order problem
  as well, independent of any NIC<->CPU bonding.

  We lose the capability to deliver an incoming packet to a different
  socket on a different CPU while we're doing protocol processing, but
  is that valuable? A net loss?

* Disable Tx interrupt altogether.  Gone. Dead.

  Instead, do the tx descriptor reaping within the driver's
  start_xmit method.  Also within the (now very occasional) Rx
  interrupt.

  This would have to be backed up with a timer of some sort.  I
  expect that a one millisecond timer would be sufficiently short to
  avoid screwing up TCP.  You'd keep pushing it back in time each time
  you reaped some Tx descriptors, so under heavy load it would never
  fire.

  If the timer _does_ fire then you can assume that there isn't much
  network load and it may be best to reenable Tx interrupts just so you
  can turn the 1 kHz timer interrupt off.

* Poll for Tx descriptor reaping in the Rx interrupt.  Poll for Rx
  packets in the start_xmit method.  Save interrupts.  With the above
  two tricks, we get *zero* interrupts per packet under heavy load.

"Ah-ha!", you say, "what about latency?".  Well, yes, this scheme
introduces up to one millisecond latency in the very specific case
where traffic is falling from a high level to a low one, which may
make it inappropriate for some classes of LAN application, but I suspect
that the effects will be low.  Plus there are a number of things here
which *decrease* latency, such as reducing the interrupt count under
load.

* Dynamic interrupt bonding.

  Some very brief testing on a 2-way indicates that TCP is a little
  more efficient when you hardwire the NIC to the CPU.

  I was thinking of a simple heuristic where you simply keep track of
  which CPU sends the most packets in a one-second time period.  At the
  end of that period, subject to some hysteresis and thresholding, bond
  the NIC's interrupt to that CPU.  Repeat each second.

  This assumes that a preponderation of Tx packet count correlates
  with one of Rx packet count, which seems fairly sane to me.

  Note that this scheme (and many other bonding schemes) will come
  horridly unstuck if multiple NICs are sharing the same interrupt!
  Don't do that.

One thing which concerns me about _any_ scheme which involves dynamic
APIC reprogramming is that wierd things are likely to happen if we
reprogram APICs when we're under load.  PCs are crap, and we're already
subject to a worrisome number of strange APIC problems.  Trying to give
the APIC a brain transplant while it is handling 5,000 interrupts per
second seems like a recipe for problems.

Last time I looked, Alphas didn't have APICs.  We need to design a
sensible architecture-neutral interrupt bonding API (or at least a
queryable one) before we run off making x86-specific changes.


As a footnote, and I know this won't be a popular view on lse-tech -
philosophically speaking I believe that 2.4 has given enough to the
big-end guys.  I hope that in 2.5, more emphasis and kernel developer
talent will be devoted to the other 99.99% of Linux users.  Better
device support, plug-n-play, manageability, upgradability, etc.  Linux
seems to be becoming more and more a server OS lately and I'd like to
see that turned around.

Of course the three-letter corps need the scalability.  Good luck to
them and thanks for supporting Linux.  For the privateers, yes, it's
*fun* to make Linux faster and it is gratifying, but we need to be
aware that it is also *easy*.  Solving the problems which are faced by
the wider community of Linux users is going to be dull, and hard.


-

From owner-netdev@oss.sgi.com Sun Dec 24 09:15:24 2000
Received:  by oss.sgi.com id <S553826AbQLXRPF>;
	Sun, 24 Dec 2000 09:15:05 -0800
Received: from shell.cyberus.ca ([209.195.95.7]:17049 "EHLO shell.cyberus.ca")
	by oss.sgi.com with ESMTP id <S553803AbQLXROp>;
	Sun, 24 Dec 2000 09:14:45 -0800
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id MAA24749;
	Sun, 24 Dec 2000 12:03:27 -0500 (EST)
X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs
Date:   Sun, 24 Dec 2000 12:03:27 -0500 (EST)
From:   jamal <hadi@cyberus.ca>
To:     Andrew Morton <andrewm@uow.edu.au>
cc:     Gerrit Huizenga <gerrit@us.ibm.com>, <timw@splhi.com>,
        Andi Kleen <ak@suse.de>, Tim Hockin <thockin@cobalt.com>,
        <npollitt@sgi.com>, <lse-tech@lists.sourceforge.net>,
        <slinx@engr.sgi.com>, <netdev@oss.sgi.com>
Subject: Re: [Lse-tech] fwd: Process Pinning
In-Reply-To: <3A4579E6.6BABBDD7@uow.edu.au>
Message-ID: <Pine.GSO.4.30.0012241000520.24639-100000@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing



I apologize for the long email. Blame Andrew Morton ;->

Since the OLS, Robert Olson and myself have been looking different
schemes to improve what i presented.

Summary:
Reported < 80Kpps at OLS for SMP. For those who missed the presentation
look at: http://robur.slu.se/Linux/net-development/jamal/FF-html/
A few tweaks on the same code and the numbers have gone upto 110Kpps on
uni-processor and 130Kpps on SMP. The main peering routers at slu.se
PCs running these patches and peering via gated/BGP.
Robert has seen in the upwards of 200Kpps on GigE without any tweaks.
We'll be presenting more precise results at NORD-USENIX in february.
We have basically exceeded the promise at OLS to do 100Mbps wire speed
(~148Kpps) by the end of the year.

In the meantime, we have each come up with slightly different schemes
that we hope will take us to that next level.
We've also discovered work done by Robert Morris at MIT on clip which is
yet a third approach, fascinating (except for the C++ part ;-<).
Robert Morris says he is able to do 333Kpps on a dual PCI SMP machine.
( it would be nice to get access to a beast like that).

In my set of experiments (done a few months ago), i have been able to get
140Kpps on a single processor and upto 190Kpps on SMP with IRQ affinity.
I belive these numbers can go higher with proper driver tuning but will peak
at some point mostly because of the APIC. Gerrit Huizenga and I had a
conversation at the OLS in which he pointed out that Linux blindly does
RR on receiving interupts and hands them to the next CPU on the list. I
have been informed that this is infact a property of the APIC ;->
I believe i am being bitten by this at the moment. I am hoping to test his
patches at some point (unfortunately this christmas break i have a more
important/exciting project i am working on).


On Sun, 24 Dec 2000, Andrew Morton wrote:

> Gerrit Huizenga wrote:
> >
> > Andi Kleen wrote:
> >
> > > You think it wouldn't help for database servers ?  (e.g. with a NIC and a
> > > SCSI controller per CPU)
> > >
> > > -Andi
> >
> > I think NIC to CPU binding would simply increase the latency problem
> > for interrupt delivery in this case.  Allowing the APIC to direct an
> > interrupt to the first available CPU decreases the average interrupt
> > delivery latency.  And, I'd guess that the interrupt latency more
> > likely governs the throughput than the sharing of a few cache lines ( 1
> > / nprocessors) of the time on most modern SMP systems.
> >
> > Of course, this depends a lot on how long a lock is held (lock_irq()).
> > I had heard that the number of instructions generally that a lock
> > was held in Linux was *very* small, although some code I've looked
> > at doesn't seem to bear that out (at least not any more).

Sounds logical. I think being able to dynamically route IRQ under some
policy mechanism (such as the one available for IRQ affinity right now)
would help a great deal.

>
> I had a few wild thoughts on this topic earlier in the year.  I haven't
> had a chance to do anything with them because people keep on putting
> bugs in the kernel :)
>
> * presume that interrupts are wickedly expensive and we want to
>   minimise them.  This is more relevant to low-end (100mbit) NICs.
>
> * presume that cross-CPU traffic and cache misses are expensive, and
>   we want to optimise for these.
>

OLS solution was interupt mitigation: Cache amortization is
achieved because you grab many packets per unit time (as well reduced
interupts are a given). This does not reduce the x-CPU traffic, of course,
but there was none introduced to start with.

> Some avenues for investigation:
>
> * Disable the NIC's interrupts at the hardware level when we're doing
>   receive processing.
>
>   This would be a big performance win on uniprocessor - there's no
>   *point* in taking the Rx interrupt when we're doing protocol
>   processing - we're just going to queue the packet and go back to
>   protocol processing.
>

If i understand you correctly, you are saying that when you are
procesing packets from the backlog, you shutdown every NICs rx interupt.

>   I think it's also a performance win on SMP.  If we're using
>   NIC->CPU bonding then it's basically a UP problem anyway.
>

I think the better idea is to totaly avoid having to do NIC->CPU bonding
and still achieve very good results.

>   So it's better to disable the Rx interrupts at the end of the Rx
>   ISR if we have sent something to netif_rx().  At the end of
>   net_rx_action() processing we call back into the driver to see if it
>   has more Rx frames available.  If there are, well, we just process
>   them as well, still with hardware interrupts disabled.  This is
>   super-quick.  If there aren't any Rx packets available, turn on
>   Rx interrupts.

OK. this is definetely a 4th way of doing things. I am not sure how you
are going to solve the fairness issue totaly but it is definetely a
different way of doing things.

>
>   Note that this magically fixes the SMP packets-out-of-order problem
>   as well, independent of any NIC<->CPU bonding.
>

I dont see how you are going to achieve this. But lately packet reodering
has become a lesser issue (at least for TCP).

>   We lose the capability to deliver an incoming packet to a different
>   socket on a different CPU while we're doing protocol processing, but
>   is that valuable? A net loss?

What do you mean by socket on different CPU?

>
> * Disable Tx interrupt altogether.  Gone. Dead.
>

>From my experiments, this is a very bad idea. Robert has also ended with
the same conclusion on a different test. The problem is the system timer
granularity. I dont think you can be more accurate than a transmit
interupt event ;->

>   Instead, do the tx descriptor reaping within the driver's
>   start_xmit method.  Also within the (now very occasional) Rx
>   interrupt.
>

I thought this was common. Maybe only on the tulip (or maybe our patched
version).

>   This would have to be backed up with a timer of some sort.  I
>   expect that a one millisecond timer would be sufficiently short to
>   avoid screwing up TCP.  You'd keep pushing it back in time each time
>   you reaped some Tx descriptors, so under heavy load it would never
>   fire.
>
>   If the timer _does_ fire then you can assume that there isn't much
>   network load and it may be best to reenable Tx interrupts just so you
>   can turn the 1 kHz timer interrupt off.

Sounds very complicated really. But i think the key is experimentation.

>
> * Poll for Tx descriptor reaping in the Rx interrupt.  Poll for Rx
>   packets in the start_xmit method.  Save interrupts.  With the above
>   two tricks, we get *zero* interrupts per packet under heavy load.
>
> "Ah-ha!", you say, "what about latency?".  Well, yes, this scheme
> introduces up to one millisecond latency in the very specific case
> where traffic is falling from a high level to a low one, which may
> make it inappropriate for some classes of LAN application, but I suspect
> that the effects will be low.  Plus there are a number of things here
> which *decrease* latency, such as reducing the interrupt count under
> load.
>

Again, i think the key is experimentation. You have generally come up with
a 4th way of doing things. The more people try different schemes, the
better. I would say implement then come up with numbers. Lets do it the
_old_ IETF way: "we believe in running code"

> * Dynamic interrupt bonding.
>

I like this idea very much. Even more i like the idea of also maintaining
the current softnet scheme of things where you have multiple
concurent softirqs, one on each processor.

>   Some very brief testing on a 2-way indicates that TCP is a little
>   more efficient when you hardwire the NIC to the CPU.
>

Which kernel was this? And what throughputs were you experimenting with?


>   I was thinking of a simple heuristic where you simply keep track of
>   which CPU sends the most packets in a one-second time period.  At the
>   end of that period, subject to some hysteresis and thresholding, bond
>   the NIC's interrupt to that CPU.  Repeat each second.
>
>   This assumes that a preponderation of Tx packet count correlates
>   with one of Rx packet count, which seems fairly sane to me.
>
>   Note that this scheme (and many other bonding schemes) will come
>   horridly unstuck if multiple NICs are sharing the same interrupt!
>   Don't do that.
>
> One thing which concerns me about _any_ scheme which involves dynamic
> APIC reprogramming is that wierd things are likely to happen if we
> reprogram APICs when we're under load.  PCs are crap, and we're already
> subject to a worrisome number of strange APIC problems.  Trying to give
> the APIC a brain transplant while it is handling 5,000 interrupts per
> second seems like a recipe for problems.
>

I think some load balancing heuristic is needed. I think the heurusitic
should _not_ be based on counting packets only but rather on CPU load.
For example, if your IDE is trashing a lot of interupts then you want to
take this into account as well. As well if a CPU is running a lot of user
processes you need to take into account those issues.

But definetely some form of dynamic IRQ routing is a good idea. Sounds
like a very exciting project (and a conference paper). From my
conversation with Gerrit they seem to have solved this. My knowledge of the
APIC is very sparse and i dont have time at the moment.
Dynamic IO-APIC reprogramming, if it can be done very efficiently is a
definete win. But like i said i dont have the knowledge there and i
believe in numbers.
Seems Gerrit and co had some scheme of figuring which CPU is least loaded
and handing the interupt to it.
Also, i am not sure how the currently highly parallel scalable softnet
scheme is going to be maintained.

> Last time I looked, Alphas didn't have APICs.  We need to design a
> sensible architecture-neutral interrupt bonding API (or at least a
> queryable one) before we run off making x86-specific changes.

How is IRQ affinity achieved on Alphas then? ;-> I thought this was a
common thing that comes in the PCI package. And if they cant do IRQ
affinity, i would say they deserve to miss this boat as well.

>
> As a footnote, and I know this won't be a popular view on lse-tech -

BTW, what is this LSE list? I just joined it.

> philosophically speaking I believe that 2.4 has given enough to the
> big-end guys.  I hope that in 2.5, more emphasis and kernel developer
> talent will be devoted to the other 99.99% of Linux users.  Better
> device support, plug-n-play, manageability, upgradability, etc.  Linux
> seems to be becoming more and more a server OS lately and I'd like to
> see that turned around.
>
> Of course the three-letter corps need the scalability.  Good luck to
> them and thanks for supporting Linux.

Andrew, I am basically in agreement with you on this, But, realistically:
do you think these three letter corps care about anything that
doesnt serve them? I dont see SGI trying to help make Linux more user
friendly or even the justification from their corporate perspective. This
also is going to affect all other "traditional" Linux companies. In fact
it might be already. It is ok to let them serve their corporate interests
as long as they help Linux. It is healthy _as long as_ there are no
competing goals at the kernel level, with one of them getting into the
kernel. Competing goals will result in Linux forks. This might not be the
case for user space (Gnome vs KDE) unless the case involves exposing some
APIs from the kernel.

> For the privateers, yes, it's
> *fun* to make Linux faster and it is gratifying, but we need to be
> aware that it is also *easy*.  Solving the problems which are faced by
> the wider community of Linux users is going to be dull, and hard.
>

I am not sure if *easy* is correct description here. Fun, yes. That is
why i participate (and maybe you as well). And if it is fun by definition
it means i do what i like. I think a combination of people like us results
in an overall improved Linux as long as there are not too many overlaps.
And even overlaps might not be a bad idea if you have plenty of time.
I find Gnome development boring, dull, and hard (not that i cant do it if
you pointed a gun at me). I am sure the Gnome people think the same about
what i do.

cheers,
jamal


From owner-netdev@oss.sgi.com Sun Dec 24 12:45:36 2000
Received:  by oss.sgi.com id <S553815AbQLXUpR>;
	Sun, 24 Dec 2000 12:45:17 -0800
Received: from monza.monza.org ([209.102.105.34]:45578 "EHLO monza.monza.org")
	by oss.sgi.com with ESMTP id <S553695AbQLXUo5>;
	Sun, 24 Dec 2000 12:44:57 -0800
Received: from internal.splhi.com ([216.99.203.57] helo=scutter.internal.splhi.com)
	by monza.monza.org with asmtp (Exim 3.14 #1)
	id 14AI0N-0008RP-00; Sun, 24 Dec 2000 20:44:31 +0000
Received: (from timw@localhost)
	by scutter.internal.splhi.com (8.11.0/8.11.0) id eBOKiN201897;
	Sun, 24 Dec 2000 12:44:23 -0800
Date:   Sun, 24 Dec 2000 12:44:23 -0800
From:   Tim Wright <timw@splhi.com>
To:     jamal <hadi@cyberus.ca>
Cc:     Andrew Morton <andrewm@uow.edu.au>,
        Gerrit Huizenga <gerrit@us.ibm.com>, timw@splhi.com,
        Andi Kleen <ak@suse.de>, Tim Hockin <thockin@cobalt.com>,
        npollitt@sgi.com, lse-tech@lists.sourceforge.net,
        slinx@engr.sgi.com, netdev@oss.sgi.com
Subject: Re: [Lse-tech] fwd: Process Pinning
Message-ID: <20001224124423.A1668@scutter.internal.splhi.com>
Reply-To: timw@splhi.com
Mail-Followup-To: jamal <hadi@cyberus.ca>,
	Andrew Morton <andrewm@uow.edu.au>,
	Gerrit Huizenga <gerrit@us.ibm.com>, timw@splhi.com,
	Andi Kleen <ak@suse.de>, Tim Hockin <thockin@cobalt.com>,
	npollitt@sgi.com, lse-tech@lists.sourceforge.net,
	slinx@engr.sgi.com, netdev@oss.sgi.com
References: <3A4579E6.6BABBDD7@uow.edu.au> <Pine.GSO.4.30.0012241000520.24639-100000@shell.cyberus.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.30.0012241000520.24639-100000@shell.cyberus.ca>; from hadi@cyberus.ca on Sun, Dec 24, 2000 at 12:03:27PM -0500
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi Jamal,
Thanks for the info and the paper pointer. This looks very interesting.
I've added a couple of comments below...

On Sun, Dec 24, 2000 at 12:03:27PM -0500, jamal wrote:
[...]
> 
> I think some load balancing heuristic is needed. I think the heurusitic
> should _not_ be based on counting packets only but rather on CPU load.
> For example, if your IDE is trashing a lot of interupts then you want to
> take this into account as well. As well if a CPU is running a lot of user
> processes you need to take into account those issues.
> 

That's the rationale/approach we took in DYNIX/ptx and it certainly works
well with large numbers of processors and high loads.

> But definitely some form of dynamic IRQ routing is a good idea. Sounds
> like a very exciting project (and a conference paper). From my
> conversation with Gerrit they seem to have solved this. My knowledge of the
> APIC is very sparse and i dont have time at the moment.
> Dynamic IO-APIC reprogramming, if it can be done very efficiently is a
> definete win. But like i said i dont have the knowledge there and i
> believe in numbers.
> Seems Gerrit and co had some scheme of figuring which CPU is least loaded
> and handing the interupt to it.

The scheme is that you tell the APIC what your current priority is. The APIC
has a task priority register, but Linux doesn't use it. We just set it to
accept-all at boot time and leave it alone. If you use it to indicate your
current priority, the APIC bus will deliver the interrupt to the least-loaded
CPU. The RR behaviour (yes I'm a Brit :-) happens if there's a choice of
"least loaded".

> 
> > Last time I looked, Alphas didn't have APICs.  We need to design a
> > sensible architecture-neutral interrupt bonding API (or at least a
> > queryable one) before we run off making x86-specific changes.
> 
> How is IRQ affinity achieved on Alphas then? ;-> I thought this was a
> common thing that comes in the PCI package. And if they cant do IRQ
> affinity, i would say they deserve to miss this boat as well.
> 

I don't know what the interrupt controller architecure is on the Alpha, but
I suspect it isn't primitive.

> >
> > As a footnote, and I know this won't be a popular view on lse-tech -
> 
> BTW, what is this LSE list? I just joined it.
> 

It's the (a?) "Linux Scalability Effort". In fact, I'm about to post a
roadmap document which tries to give a better feel for what we wanted to
achieve here. In a nutshell, it's "what can we do to make Linux run better
on big iron, *without* breaking it on uni-proc/embedded systems".

> > philosophically speaking I believe that 2.4 has given enough to the
> > big-end guys.  I hope that in 2.5, more emphasis and kernel developer
> > talent will be devoted to the other 99.99% of Linux users.  Better
> > device support, plug-n-play, manageability, upgradability, etc.  Linux
> > seems to be becoming more and more a server OS lately and I'd like to
> > see that turned around.
> >
> > Of course the three-letter corps need the scalability.  Good luck to
> > them and thanks for supporting Linux.
> 

There are people in the Linux Technology Center at IBM working on a number
of the above. It just so happens that people like Gerrit and myself work for
the company formally known as Sequent (we were bought by IBM), and hence
our area of expertise is large-scale SMP and NUMA systems.

> > For the privateers, yes, it's
> > *fun* to make Linux faster and it is gratifying, but we need to be
> > aware that it is also *easy*.  Solving the problems which are faced by
> > the wider community of Linux users is going to be dull, and hard.
> >
> 
> I am not sure if *easy* is correct description here. Fun, yes. That is
> why i participate (and maybe you as well). And if it is fun by definition
> it means i do what i like. I think a combination of people like us results
> in an overall improved Linux as long as there are not too many overlaps.
> And even overlaps might not be a bad idea if you have plenty of time.
> I find Gnome development boring, dull, and hard (not that i cant do it if
> you pointed a gun at me). I am sure the Gnome people think the same about
> what i do.
> 

Indeed. I'm unconvinced that working on the kernel is easy, at least not
in comparison to programing in userland. There are people who are scared
witless a the thought of kernel work, but are totally at home (and highly)
skilled working on applications. I do think there is a great deal more work
to be done in userland then on the kernel, and I sincerely hope that enough
people can be found to do it. It's just not my area of expertise.

Regards,

Tim

-- 
Tim Wright - timw@splhi.com or timw@aracnet.com or twright@us.ibm.com
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI

From owner-netdev@oss.sgi.com Sun Dec 24 17:02:17 2000
Received:  by oss.sgi.com id <S553786AbQLYBCI>;
	Sun, 24 Dec 2000 17:02:08 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:22291 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S553705AbQLYBBz>;
	Sun, 24 Dec 2000 17:01:55 -0800
Received: (qmail 25665 invoked from network); 25 Dec 2000 01:01:49 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 25 Dec 2000 01:01:49 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@ocs.com.au>
To:     netdev@oss.sgi.com
Subject: net link order
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Mon, 25 Dec 2000 12:01:48 +1100
Message-ID: <1378.977706108@ocs3.ocs-net>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

I am documenting the requirements for link order across the net
directories and need some input.  net/Makefile (2.4.0-test13-pre4)
links directories in the order below, but there is no way of telling if
this order is required or is just historical.

Assuming that everything is linked into the kernel, which init routines
depend on other init code having already run?  Ignore link order within
net directories, this is documenting inter-directory link order
requirements.  For example,

ipv4 must be linked before ipv4/netfilter because ...
foo must be linked before bar because ...

subdir-$(CONFIG_NET)            += 802 sched		sched appears twice, why?
subdir-$(CONFIG_INET)           += ipv4
subdir-$(CONFIG_NETFILTER)      += ipv4/netfilter
subdir-$(CONFIG_UNIX)           += unix
subdir-$(CONFIG_IPV6)           += ipv6

ifneq ($(CONFIG_IPV6),n)
ifneq ($(CONFIG_IPV6),)
subdir-$(CONFIG_NETFILTER)      += ipv6/netfilter
endif
endif

subdir-$(CONFIG_KHTTPD)         += khttpd
subdir-$(CONFIG_NETLINK)        += netlink
subdir-$(CONFIG_PACKET)         += packet
subdir-$(CONFIG_NET_SCHED)      += sched		sched appears twice, why?
subdir-$(CONFIG_BRIDGE)         += bridge
subdir-$(CONFIG_IPX)            += ipx
subdir-$(CONFIG_ATALK)          += appletalk
subdir-$(CONFIG_WAN_ROUTER)     += wanrouter		no init
subdir-$(CONFIG_X25)            += x25
subdir-$(CONFIG_LAPB)           += lapb
subdir-$(CONFIG_NETROM)         += netrom
subdir-$(CONFIG_ROSE)           += rose
subdir-$(CONFIG_AX25)           += ax25
subdir-$(CONFIG_IRDA)           += irda
subdir-$(CONFIG_SUNRPC)         += sunrpc		no init
subdir-$(CONFIG_ATM)            += atm
subdir-$(CONFIG_DECNET)         += decnet
subdir-$(CONFIG_ECONET)         += econet


From owner-netdev@oss.sgi.com Sun Dec 24 19:00:58 2000
Received:  by oss.sgi.com id <S553869AbQLYDAi>;
	Sun, 24 Dec 2000 19:00:38 -0800
Received: from shell.cyberus.ca ([209.195.95.7]:49561 "EHLO shell.cyberus.ca")
	by oss.sgi.com with ESMTP id <S553797AbQLYDA3>;
	Sun, 24 Dec 2000 19:00:29 -0800
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id VAA25254;
	Sun, 24 Dec 2000 21:59:34 -0500 (EST)
X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs
Date:   Sun, 24 Dec 2000 21:59:34 -0500 (EST)
From:   jamal <hadi@cyberus.ca>
To:     Tim Wright <timw@splhi.com>
cc:     Andrew Morton <andrewm@uow.edu.au>,
        Gerrit Huizenga <gerrit@us.ibm.com>, Andi Kleen <ak@suse.de>,
        Tim Hockin <thockin@cobalt.com>, <npollitt@sgi.com>,
        <lse-tech@lists.sourceforge.net>, <slinx@engr.sgi.com>,
        <netdev@oss.sgi.com>
Subject: Re: [Lse-tech] fwd: Process Pinning
In-Reply-To: <20001224124423.A1668@scutter.internal.splhi.com>
Message-ID: <Pine.GSO.4.30.0012242146480.24639-100000@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing



On Sun, 24 Dec 2000, Tim Wright wrote:

> The scheme is that you tell the APIC what your current priority is. The APIC
> has a task priority register, but Linux doesn't use it. We just set it to
> accept-all at boot time and leave it alone. If you use it to indicate your
> current priority, the APIC bus will deliver the interrupt to the least-loaded
> CPU. The RR behaviour (yes I'm a Brit :-) happens if there's a choice of
> "least loaded".

So it seems that the process is capable of setting a high enough priority
such that an (hardware) interupt wont run on a specific CPU?
My goal might be slightly different than this. I would like to route
interupts to CPUs which have the "least load of interupts" in addition
to process load.
do you have a paper on this, maybe you can already do this?

cheers,
jamal


From owner-netdev@oss.sgi.com Mon Dec 25 01:00:40 2000
Received:  by oss.sgi.com id <S553810AbQLYJAV>;
	Mon, 25 Dec 2000 01:00:21 -0800
Received: from monza.monza.org ([209.102.105.34]:3596 "EHLO monza.monza.org")
	by oss.sgi.com with ESMTP id <S553798AbQLYI7u>;
	Mon, 25 Dec 2000 00:59:50 -0800
Received: from internal.splhi.com ([216.99.203.57] helo=scutter.internal.splhi.com)
	by monza.monza.org with asmtp (Exim 3.14 #1)
	id 14ATTq-0000tK-00; Mon, 25 Dec 2000 08:59:43 +0000
Received: (from timw@localhost)
	by scutter.internal.splhi.com (8.11.0/8.11.0) id eBP8xYu02310;
	Mon, 25 Dec 2000 00:59:34 -0800
Date:   Mon, 25 Dec 2000 00:59:34 -0800
From:   Tim Wright <timw@splhi.com>
To:     jamal <hadi@cyberus.ca>
Cc:     Tim Wright <timw@splhi.com>, Andrew Morton <andrewm@uow.edu.au>,
        Gerrit Huizenga <gerrit@us.ibm.com>, Andi Kleen <ak@suse.de>,
        Tim Hockin <thockin@cobalt.com>, npollitt@sgi.com,
        lse-tech@lists.sourceforge.net, slinx@engr.sgi.com,
        netdev@oss.sgi.com
Subject: Re: [Lse-tech] fwd: Process Pinning
Message-ID: <20001225005934.A2307@scutter.internal.splhi.com>
Reply-To: timw@splhi.com
Mail-Followup-To: jamal <hadi@cyberus.ca>, Tim Wright <timw@splhi.com>,
	Andrew Morton <andrewm@uow.edu.au>,
	Gerrit Huizenga <gerrit@us.ibm.com>, Andi Kleen <ak@suse.de>,
	Tim Hockin <thockin@cobalt.com>, npollitt@sgi.com,
	lse-tech@lists.sourceforge.net, slinx@engr.sgi.com,
	netdev@oss.sgi.com
References: <20001224124423.A1668@scutter.internal.splhi.com> <Pine.GSO.4.30.0012242146480.24639-100000@shell.cyberus.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.30.0012242146480.24639-100000@shell.cyberus.ca>; from hadi@cyberus.ca on Sun, Dec 24, 2000 at 09:59:34PM -0500
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sun, Dec 24, 2000 at 09:59:34PM -0500, jamal wrote:
> 
> 
> On Sun, 24 Dec 2000, Tim Wright wrote:
> 
> > The scheme is that you tell the APIC what your current priority is. The APIC
> > has a task priority register, but Linux doesn't use it. We just set it to
> > accept-all at boot time and leave it alone. If you use it to indicate your
> > current priority, the APIC bus will deliver the interrupt to the least-loaded
> > CPU. The RR behaviour (yes I'm a Brit :-) happens if there's a choice of
> > "least loaded".
> 
> So it seems that the process is capable of setting a high enough priority
> such that an (hardware) interupt wont run on a specific CPU?

No, all user processes are pre-emptible. DYNIX/ptx doesn't support the notion
of RT processes. The range of user priorities is crunched down into 4 bits.
Locking out of interrupts below a given SPL is achieved by programming a
different register IIRC, although it is also mirrored in the TPR (task
priority register), and SPL1 is "higher" priority than any user process.

> My goal might be slightly different than this. I would like to route
> interupts to CPUs which have the "least load of interupts" in addition
> to process load.
> do you have a paper on this, maybe you can already do this?
> 

That is what we do. I don't know if we have a paper, but it sounds like we
should. It's actually quite likely that I can publish the relevant code
with little difficulty.

Regards,

Tim

-- 
Tim Wright - timw@splhi.com or timw@aracnet.com or twright@us.ibm.com
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI

From owner-netdev@oss.sgi.com Mon Dec 25 07:44:43 2000
Received:  by oss.sgi.com id <S553812AbQLYPoX>;
	Mon, 25 Dec 2000 07:44:23 -0800
Received: from laurin.munich.netsurf.de ([194.64.166.1]:41658 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S553805AbQLYPn4>; Mon, 25 Dec 2000 07:43:56 -0800
Received: from fred.muc.de (noidentity@ns1153.munich.netsurf.de [195.180.235.153])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id QAA20667;
	Mon, 25 Dec 2000 16:43:42 +0100 (MET)
Received: by fred.muc.de (Postfix, from userid 500)
	id A8337E3913; Mon, 25 Dec 2000 16:40:07 +0100 (CET)
Date:   Mon, 25 Dec 2000 16:40:07 +0100
From:   Andi Kleen <ak@muc.de>
To:     Keith Owens <kaos@ocs.com.au>
Cc:     netdev@oss.sgi.com
Subject: Re: net link order
Message-ID: <20001225164007.A5844@fred.local>
References: <1378.977706108@ocs3.ocs-net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <1378.977706108@ocs3.ocs-net>; from kaos@ocs.com.au on Mon, Dec 25, 2000 at 02:03:03AM +0100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, Dec 25, 2000 at 02:03:03AM +0100, Keith Owens wrote:
> Assuming that everything is linked into the kernel, which init routines
> depend on other init code having already run?  Ignore link order within
> net directories, this is documenting inter-directory link order
> requirements.  For example,

I doubt anybody really knows what subtle interaction are there.  Better do
not mess with the order at all.

> ipv4 must be linked before ipv4/netfilter because ...
> foo must be linked before bar because ...
> 
> subdir-$(CONFIG_NET)            += 802 sched		sched appears twice, why?

sched/sch_generic.c must be active even when CONFIG_SCHED is not enabled
(otherwise you wouldn't be able to queue anything to devices) 


-Andi

From owner-netdev@oss.sgi.com Mon Dec 25 08:14:46 2000
Received:  by oss.sgi.com id <S553827AbQLYQOg>;
	Mon, 25 Dec 2000 08:14:36 -0800
Received: from shell.cyberus.ca ([209.195.95.7]:9882 "EHLO shell.cyberus.ca")
	by oss.sgi.com with ESMTP id <S553811AbQLYQOM>;
	Mon, 25 Dec 2000 08:14:12 -0800
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id LAA25767;
	Mon, 25 Dec 2000 11:13:11 -0500 (EST)
X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs
Date:   Mon, 25 Dec 2000 11:13:11 -0500 (EST)
From:   jamal <hadi@cyberus.ca>
To:     Tim Wright <timw@splhi.com>
cc:     Andrew Morton <andrewm@uow.edu.au>,
        Gerrit Huizenga <gerrit@us.ibm.com>, Andi Kleen <ak@suse.de>,
        Tim Hockin <thockin@cobalt.com>, <npollitt@sgi.com>,
        <lse-tech@lists.sourceforge.net>, <slinx@engr.sgi.com>,
        <netdev@oss.sgi.com>
Subject: Re: [Lse-tech] fwd: Process Pinning
In-Reply-To: <20001225005934.A2307@scutter.internal.splhi.com>
Message-ID: <Pine.GSO.4.30.0012251058400.25601-100000@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing



On Mon, 25 Dec 2000, Tim Wright wrote:

> On Sun, Dec 24, 2000 at 09:59:34PM -0500, jamal wrote:
> >
> >
> > So it seems that the process is capable of setting a high enough priority
> > such that an (hardware) interupt wont run on a specific CPU?
>
> No, all user processes are pre-emptible. DYNIX/ptx doesn't support the notion
> of RT processes. The range of user priorities is crunched down into 4 bits.
> Locking out of interrupts below a given SPL is achieved by programming a
> different register IIRC, although it is also mirrored in the TPR (task
> priority register), and SPL1 is "higher" priority than any user process.

I see. I think i understand what Andi was saying earlier. You are
generally proposing some bsdish SPL* scheme which also applies to
hardware interupts(?). i.e it looks to me with your idea, you might
lower the priority of a hardware interupt. Seems like our goals might
intersect somewhere b ut not as simple as i thought earlier.
In essence, i am looking for some way to define sophisticated interupt
scheduling via a policy.

Simple example of what i'd like to experiment with:
A policy such as : "IRQ3 and IRQ5 are mutually exclusive". The mechanism
should then ensure that at any point in time if IRQ3 and IRQ5 get set
they get routed to two different CPUs.

> That is what we do. I don't know if we have a paper, but it sounds like we
> should. It's actually quite likely that I can publish the relevant code
> with little difficulty.
>

Code would help.

cheers,
jamal


From owner-netdev@oss.sgi.com Mon Dec 25 09:55:36 2000
Received:  by oss.sgi.com id <S553834AbQLYRz0>;
	Mon, 25 Dec 2000 09:55:26 -0800
Received: from monza.monza.org ([209.102.105.34]:2833 "EHLO monza.monza.org")
	by oss.sgi.com with ESMTP id <S553819AbQLYRzA>;
	Mon, 25 Dec 2000 09:55:00 -0800
Received: from internal.splhi.com ([216.99.203.57] helo=scutter.internal.splhi.com)
	by monza.monza.org with asmtp (Exim 3.14 #1)
	id 14Abpn-0001WR-00; Mon, 25 Dec 2000 17:54:55 +0000
Received: (from timw@localhost)
	by scutter.internal.splhi.com (8.11.0/8.11.0) id eBPHskU02887;
	Mon, 25 Dec 2000 09:54:46 -0800
Date:   Mon, 25 Dec 2000 09:54:46 -0800
From:   Tim Wright <timw@splhi.com>
To:     jamal <hadi@cyberus.ca>
Cc:     Tim Wright <timw@splhi.com>, Andrew Morton <andrewm@uow.edu.au>,
        Gerrit Huizenga <gerrit@us.ibm.com>, Andi Kleen <ak@suse.de>,
        Tim Hockin <thockin@cobalt.com>, npollitt@sgi.com,
        lse-tech@lists.sourceforge.net, slinx@engr.sgi.com,
        netdev@oss.sgi.com
Subject: Re: [Lse-tech] fwd: Process Pinning
Message-ID: <20001225095446.A2872@scutter.internal.splhi.com>
Reply-To: timw@splhi.com
Mail-Followup-To: jamal <hadi@cyberus.ca>, Tim Wright <timw@splhi.com>,
	Andrew Morton <andrewm@uow.edu.au>,
	Gerrit Huizenga <gerrit@us.ibm.com>, Andi Kleen <ak@suse.de>,
	Tim Hockin <thockin@cobalt.com>, npollitt@sgi.com,
	lse-tech@lists.sourceforge.net, slinx@engr.sgi.com,
	netdev@oss.sgi.com
References: <20001225005934.A2307@scutter.internal.splhi.com> <Pine.GSO.4.30.0012251058400.25601-100000@shell.cyberus.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.30.0012251058400.25601-100000@shell.cyberus.ca>; from hadi@cyberus.ca on Mon, Dec 25, 2000 at 11:13:11AM -0500
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, Dec 25, 2000 at 11:13:11AM -0500, jamal wrote:
> 
> 
> On Mon, 25 Dec 2000, Tim Wright wrote:
> 
> > On Sun, Dec 24, 2000 at 09:59:34PM -0500, jamal wrote:
> > >
> > >
> > > So it seems that the process is capable of setting a high enough priority
> > > such that an (hardware) interupt wont run on a specific CPU?
> >
> > No, all user processes are pre-emptible. DYNIX/ptx doesn't support the notion
> > of RT processes. The range of user priorities is crunched down into 4 bits.
> > Locking out of interrupts below a given SPL is achieved by programming a
> > different register IIRC, although it is also mirrored in the TPR (task
> > priority register), and SPL1 is "higher" priority than any user process.
> 
> I see. I think i understand what Andi was saying earlier. You are
> generally proposing some bsdish SPL* scheme which also applies to
> hardware interupts(?). i.e it looks to me with your idea, you might
> lower the priority of a hardware interupt.

The SPL stuff predates BSD by a long way. It was in 6th edition and probably
earlier than that. I wouldn't say the we "lower" the priority, but we do have
a hierarchy such that there are lower priority interrupt routines that can
be pre-empted by higher priority ones. However, it is not necessary to go to
these lengths to take advantage of the APIC priority stuff. It is nowehere
written in stone that there have to be eight interrupt priority levels. If we
were to choose two, for instance, that collapses down to map simply to what
Linux uses today, except that by replacing cli/sti we would achieve sane
interrupt distribution.

> Seems like our goals might
> intersect somewhere b ut not as simple as i thought earlier.
> In essence, i am looking for some way to define sophisticated interupt
> scheduling via a policy.
> 

I suspect we're closer together than you might think. The SPL hierarchy thing
may turn out to be less valuable than the complexity justifies. The first
thing to do is to change the APIC programming.

> Simple example of what i'd like to experiment with:
> A policy such as : "IRQ3 and IRQ5 are mutually exclusive". The mechanism
> should then ensure that at any point in time if IRQ3 and IRQ5 get set
> they get routed to two different CPUs.
> 

I'd need to think about that. I'm not sure how practical that is on an x86.
Of course, the way it's done in ptx would guarantee that provided that at
least one cpu in the system wasn't already busy in an interrupt routine.

> > That is what we do. I don't know if we have a paper, but it sounds like we
> > should. It's actually quite likely that I can publish the relevant code
> > with little difficulty.
> >
> 
> Code would help.
> 

Will work on it....
Watch this space :-)

Regards,

Tim

-- 
Tim Wright - timw@splhi.com or timw@aracnet.com or twright@us.ibm.com
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI

From owner-netdev@oss.sgi.com Wed Dec 27 06:35:21 2000
Received:  by oss.sgi.com id <S553712AbQL0OfM>;
	Wed, 27 Dec 2000 06:35:12 -0800
Received: from isis.its.uow.edu.au ([130.130.68.21]:57221 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S553668AbQL0Oes>;
	Wed, 27 Dec 2000 06:34:48 -0800
Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12])
	by isis.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id BAA23328;
	Thu, 28 Dec 2000 01:34:24 +1100 (EST)
Message-ID: <3A49FF32.5F53DB26@uow.edu.au>
Date:   Thu, 28 Dec 2000 01:39:46 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>
CC:     lkml <linux-kernel@vger.kernel.org>, netdev@oss.sgi.com
Subject: [patch] remove usage of init_etherdev
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Alan,

I have just sent you the prepare/withdraw/publish_etherdev patch for the ethernet
devices.  There's a copy (80kbytes) at

	http://www.uow.edu.au/~andrewm/linux/init_etherdev.patch

It was fairly clean and I don't expect much breakage at all from this. 
I could only test the module and non-module error paths, but surely
this patch represents an aggregate bug reduction :)

eepro100.c and acenic.c should still be 2.2-compatible.

The patch includes some other xmas goodies, including:

- An update to 3c59x which allows it to support 3com's
  recently-released 3c905CX.  This is a bit ugly, but it gets people up
  and running until I can get my hands on one of these things.  

- Fixed locking and write barriers in natsemi.c, as discussed with Manfred.

- Fixed a fair number of unchecked kmallocs and error-path resource leaks.

- comx.c needs proc_get_inode(), so that has been exported.

- dmfe.c was allowing itself to be unloaded whilst remaining
  registered on the PCI device list.  crash, crash.

- Several drivers were not declaring their module parms and were not
  loadable with recent modutils.

- Several drivers had incorrect module parm declarations are were not
  loadable with recent modutils.

- All affected drivers now use SET_MODULE_OWNER instead of MOD_INC/DEC.

- drivers/net/depca.c oopses on boot because egcs-1.1.2 is
  miscompiling strstr().  It's failing to honour the clobber on edi.  I
  put a workaround in depca.c.

  A workaround in strstr is to force `ct' to be a memory operand, not
  a general operand.  Shouldn't we do this? Or, even better, kill the
  asm strstr and use the one in lib/string.c?


I think aironet4500_card.c is missing some module refcount handling,
but I didn't address this.

I'll send you the rrunner.c patch (maybe Jes has already done so?). 
Then if/when this stuff comes back to me I can do a final patch to
remove the now-unused init_etherdev, init_fcdev, init_hip_dev,
init_fddidev and init_trdev functions.  Then we're done.

The CardServices drivers use a bare register_netdev() and I think they
have the same race.  But that's orthogonal to the current work.

Thanks.


Affected files:


arch/ppc/8xx_io/enet.c
arch/ppc/8xx_io/fec.c
arch/ppc/8260_io/enet.c
arch/ppc/8260_io/fcc_enet.c
drivers/net/3c509.c
drivers/net/lance.c
drivers/net/atp.c
drivers/net/tlan.c
drivers/net/sunbmac.c
drivers/net/sk_g16.c
drivers/net/3c59x.c
drivers/net/acenic.c
drivers/net/sunlance.c
drivers/net/sunhme.c
drivers/net/a2065.c
drivers/net/hydra.c
drivers/net/ariadne.c
drivers/net/myri_sbus.c
drivers/net/sunqe.c
drivers/net/atari_bionet.c
drivers/net/atari_pamsnet.c
drivers/net/eepro100.c
drivers/net/ncr885e.c
drivers/net/starfire.c
drivers/net/pcnet32.c
drivers/net/via-rhine.c
drivers/net/yellowfin.c
drivers/net/oaknet.c
drivers/net/sis900.c
drivers/net/arlan.c
drivers/net/mace.c
drivers/net/am79c961a.c
drivers/net/epic100.c
drivers/net/ne2k-pci.c
drivers/net/hplance.c
drivers/net/bmac.c
drivers/net/sb1000.c
drivers/net/dmfe.c
drivers/net/gmac.c
drivers/net/daynaport.c
drivers/net/8139too.c
drivers/net/3c515.c
drivers/net/sk98lin/skge.c
drivers/net/tulip/tulip_core.c
drivers/net/bagetlance.c
drivers/net/declance.c
drivers/net/stnic.c
drivers/net/ioc3-eth.c
drivers/net/macsonic.c
drivers/net/sun3lance.c
drivers/net/pcmcia/aironet4500_cs.c
drivers/net/pcmcia/xircom_tulip_cb.c
drivers/net/aironet4500_card.c
drivers/net/aironet4500_core.c
drivers/net/macmace.c
drivers/net/rtl8129.c
drivers/net/natsemi.c
drivers/net/hamachi.c
drivers/net/sundance.c
drivers/net/winbond-840.c
drivers/net/depca.c
drivers/acorn/net/ether1.c
drivers/acorn/net/ether3.c
drivers/acorn/net/etherh.c
drivers/usb/pegasus.c

fs/proc/procfs_syms.c

-

From owner-netdev@oss.sgi.com Sun Dec 31 05:29:12 2000
Received:  by oss.sgi.com id <S553783AbQLaN2x>;
	Sun, 31 Dec 2000 05:28:53 -0800
Received: from mail.sun.ac.za ([146.232.128.1]:13578 "EHLO mail.sun.ac.za")
	by oss.sgi.com with ESMTP id <S553780AbQLaN2a>;
	Sun, 31 Dec 2000 05:28:30 -0800
Received: from prime.sun.ac.za ([146.232.164.2])
	by mail.sun.ac.za with esmtp (Exim 2.10 #1)
	id 14CiX4-0004ID-00
	for netdev@oss.sgi.com; Sun, 31 Dec 2000 15:28:18 +0200
Received: from grobh (helo=localhost)
	by prime.sun.ac.za with local-esmtp (Exim 3.20 #1)
	id 14CiX4-0000Yu-00
	for netdev@oss.sgi.com; Sun, 31 Dec 2000 15:28:18 +0200
Date:   Sun, 31 Dec 2000 15:28:18 +0200 (SAST)
From:   Hans Grobler <grobh@sun.ac.za>
To:     <netdev@oss.sgi.com>
Subject: Re: netdevice interface changes in 2.4.0test13pre4ac1
In-Reply-To: <3A4448DE.DEE4C43C@uow.edu.au>
Message-ID: <Pine.LNX.4.30.0012311504440.675-100000@prime.sun.ac.za>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sat, 23 Dec 2000, Andrew Morton wrote:
>      unregister_netdev()
>
>           This function remains in place.  Should only be
>           called for an unhidden interface.  It closes the device,
>           removes the interface from the namespace, notifies protocols
>           of the disappearing interface and then calls /sbin/hotplug.

Comments in this function talk about "New style" devices with destructors.
The current implementation blocks until the device reference count reaches
1. The comment appears to imply that at some point in the future this
routine will not block if it detects a new style device. The cleanup will
then be done via the destructor.

However, where the destructor is called in netdev_finish_unregister, the
dev handle is again dereferenced after the destructor has been called.

Does this imply that the destructor cannot be used to deallocate the
device structure (i.e. dev->features & NETIF_F_DYNALLOC = 0)?

Or is the dev handle assume to still be valid?

Or would the patch below be desired?

Or could someone give an indication to what the destructor is allowed to
destroy...

Thanks,
-- Hans.


diff -u4Nr -X dontdiff linux-2.4.0test13pre7.orig/net/core/dev.c linux-2.4.0test13pre7/net/core/dev.c
--- linux-2.4.0test13pre7.orig/net/core/dev.c	Mon Dec 11 21:29:35 2000
+++ linux-2.4.0test13pre7/net/core/dev.c	Sun Dec 31 13:16:41 2000
@@ -2418,8 +2418,10 @@
  */

 int netdev_finish_unregister(struct net_device *dev)
 {
+	int features = dev->features;
+
 	BUG_TRAP(dev->ip_ptr==NULL);
 	BUG_TRAP(dev->ip6_ptr==NULL);
 	BUG_TRAP(dev->dn_ptr==NULL);

@@ -2432,9 +2434,9 @@
 	       (dev->features & NETIF_F_DYNALLOC)?"":", old style");
 #endif
 	if (dev->destructor)
 		dev->destructor(dev);
-	if (dev->features & NETIF_F_DYNALLOC)
+	if (features & NETIF_F_DYNALLOC)
 		kfree(dev);
 	return 0;
 }