From owner-netdev@oss.sgi.com Fri Sep  1 04:02:39 2000
Received:  by oss.sgi.com id <S42292AbQIALCU>;
	Fri, 1 Sep 2000 04:02:20 -0700
Received: from jil.informatik.uni-rostock.de ([139.30.5.243]:15358 "EHLO
        jil.informatik.uni-rostock.de") by oss.sgi.com with ESMTP
	id <S42268AbQIALBs>; Fri, 1 Sep 2000 04:01:48 -0700
Received: from hokkaido.informatik.uni-rostock.de (echter@hokkaido [139.30.1.235])
	by jil.informatik.uni-rostock.de (8.9.3/8.9.3/relay3.3) with ESMTP id NAA16160
	for <netdev@oss.sgi.com>; Fri, 1 Sep 2000 13:01:41 +0200 (MET DST)
Received: (from echter@localhost)
	by hokkaido.informatik.uni-rostock.de (8.8.5/8.8.5/fin2.0) id NAA08067
	for netdev@oss.sgi.com; Fri, 1 Sep 2000 13:01:40 +0200 (MET DST)
Date:   Fri, 1 Sep 2000 13:01:40 +0200
From:   Jan Echternach <echter@informatik.uni-rostock.de>
To:     netdev@oss.sgi.com
Subject: [PATCH] possible netlink_set_err() fix
Message-ID: <20000901130140.B7475@hokkaido.informatik.uni-rostock.de>
Reply-To: Jan Echternach <jan.echternach@informatik.uni-rostock.de>
Mail-Followup-To: netdev@oss.sgi.com
References: <20000816173416.A27392@hokkaido.informatik.uni-rostock.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="neYutvxvOLaeuPCA"
X-Mailer: Mutt 1.0i
In-Reply-To: <20000816173416.A27392@hokkaido.informatik.uni-rostock.de>; from echter@informatik.uni-rostock.de on Wed, Aug 16, 2000 at 05:34:16PM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


--neYutvxvOLaeuPCA
Content-Type: text/plain; charset=us-ascii

Hi,

I'm not sure if this patch for 2.4.0-test7 is correct, but it makes
netlink_set_err() behave the same as netlink_overrun() in that it tests
the bit 0 of sk->protinfo.af_netlink->state before actually setting the
error.

-- 
Jan

--neYutvxvOLaeuPCA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="patch-2.4.0-test7-seterr1"

--- linux-2.4.0-test7/net/netlink/af_netlink.c-test7	Tue Aug  1 00:30:29 2000
+++ linux-2.4.0-test7/net/netlink/af_netlink.c	Thu Aug 31 14:42:56 2000
@@ -539,8 +539,10 @@
 		    !(sk->protinfo.af_netlink->groups&group))
 			continue;
 
-		sk->err = code;
-		sk->error_report(sk);
+		if (!test_and_set_bit(0, &sk->protinfo.af_netlink->state)) {
+			sk->err = code;
+			sk->error_report(sk);
+		}
 	}
 	read_unlock(&nl_table_lock);
 }

--neYutvxvOLaeuPCA--

From owner-netdev@oss.sgi.com Fri Sep  1 04:22:38 2000
Received:  by oss.sgi.com id <S42294AbQIALW2>;
	Fri, 1 Sep 2000 04:22:28 -0700
Received: from jil.informatik.uni-rostock.de ([139.30.5.243]:29056 "EHLO
        jil.informatik.uni-rostock.de") by oss.sgi.com with ESMTP
	id <S42268AbQIALWR>; Fri, 1 Sep 2000 04:22:17 -0700
Received: from hokkaido.informatik.uni-rostock.de (echter@hokkaido [139.30.1.235])
	by jil.informatik.uni-rostock.de (8.9.3/8.9.3/relay3.3) with ESMTP id NAA16383
	for <netdev@oss.sgi.com>; Fri, 1 Sep 2000 13:22:12 +0200 (MET DST)
Received: (from echter@localhost)
	by hokkaido.informatik.uni-rostock.de (8.8.5/8.8.5/fin2.0) id NAA08402
	for netdev@oss.sgi.com; Fri, 1 Sep 2000 13:22:11 +0200 (MET DST)
Date:   Fri, 1 Sep 2000 13:22:11 +0200
From:   Jan Echternach <echter@informatik.uni-rostock.de>
To:     netdev@oss.sgi.com
Subject: [PATCH] NLMSG_OK fix
Message-ID: <20000901132211.C7475@hokkaido.informatik.uni-rostock.de>
Reply-To: Jan Echternach <jan.echternach@informatik.uni-rostock.de>
Mail-Followup-To: netdev@oss.sgi.com
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="/e2eDi0V/xtL+Mc8"
X-Mailer: Mutt 1.0i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


--/e2eDi0V/xtL+Mc8
Content-Type: text/plain; charset=us-ascii

Hi,

NLMSG_OK in 2.4.0-test7 has three problems:

(1) nlmsg_len is read before it is checked that the message is long
enough

(2) sizes are compared with unaligned size of struct nlmsghdr

(3) compiler warnings (comparision between signed and unsigned) if the
len parameter is signed

I'm not sure if (2) is really a problem.  Messages without full padding
at the end can be useful (and are accepted by rtnetlink_rcv_skb(), for
instance), even though this has odd effects like nlmsg_len being
smaller than NLMSG_LENGTH(0) or NLMSG_NEXT decrementing its 'len'
parameter below 0 (which requires that len must be signed, NLMSG_NEXT
won't work correctly otherwise).  The patch is incorrect if such
messages are valid.  In this case you may only want to change the len >
0 check in NLMSG_OK to len >= sizeof(struct nlmsghdr).

-- 
Jan

--/e2eDi0V/xtL+Mc8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="patch-2.4.0-test7-nlmsgok2"

--- linux-2.4.0-test7/include/linux/netlink.h-test7	Fri Aug 28 04:33:08 1998
+++ linux-2.4.0-test7/include/linux/netlink.h	Thu Aug 31 16:07:25 2000
@@ -64,8 +64,9 @@
 #define NLMSG_DATA(nlh)  ((void*)(((char*)nlh) + NLMSG_LENGTH(0)))
 #define NLMSG_NEXT(nlh,len)	 ((len) -= NLMSG_ALIGN((nlh)->nlmsg_len), \
 				  (struct nlmsghdr*)(((char*)(nlh)) + NLMSG_ALIGN((nlh)->nlmsg_len)))
-#define NLMSG_OK(nlh,len) ((len) > 0 && (nlh)->nlmsg_len >= sizeof(struct nlmsghdr) && \
-			   (nlh)->nlmsg_len <= (len))
+#define NLMSG_OK(nlh,len) ((len) >= (long) NLMSG_LENGTH(0) \
+                           && (nlh)->nlmsg_len >= NLMSG_LENGTH(0) \
+                           && (len) + 0ul >= NLMSG_ALIGN((nlh)->nlmsg_len))
 #define NLMSG_PAYLOAD(nlh,len) ((nlh)->nlmsg_len - NLMSG_SPACE((len)))
 
 #define NLMSG_NOOP		0x1	/* Nothing.		*/

--/e2eDi0V/xtL+Mc8--

From owner-netdev@oss.sgi.com Sat Sep  2 09:22:45 2000
Received:  by oss.sgi.com id <S42508AbQIBQWf>;
	Sat, 2 Sep 2000 09:22:35 -0700
Received: from kogge.hanse.de ([192.76.134.17]:9738 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S42360AbQIBQWN>;
	Sat, 2 Sep 2000 09:22:13 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id SAA17644;
	Sat, 2 Sep 2000 18:26:29 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id SAA14078;
	Sat, 2 Sep 2000 18:11:46 +0200
Date:   Sat, 2 Sep 2000 18:11:46 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200009021611.SAA14078@baty.hanse.de>
To:     linux-x25@vger.kernel.org, netdev@oss.sgi.com
Subject: sk_tunnel -- IP and PPP tunnel over X.25 (and maybe other ..)
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Hi,

For those who ever asked how to tunnel IP or PPP over Linux X.25:
Please have a look at

       http://www.baty.hanse.de/linux-x25/sk_tunnel

As this is the first public release (alpha) it might be buggy.

Features:

- Supports tunneling PPP and raw-IP over the Linux PF_X25 sockets.
- Tunnel data remains in kernel.
- Connection control and policy decisions fully remain in user
  space, using the standard socket API.
- Uses standard ppp_generic inside kernel and pppd in user space.
- Should be re-usable for other Linux protocol stacks which provide
  a socket API with SOCK_DGRAM or SOCK_SEQPACKET semantics.

The latter still needs to be proved (and of corse, it will still
require knowledge and work to interface it with other protocol stacks).
The design definitely intends to be re-usable. The files of the
initial alpha test release are however placed inside the net/x25.
directory. I´m very interested in comments from maintainers of other
linux protocol stacks who intend to support IP or PPP tunneling
over their protocol stack. Do you think the stuff is useful and fits
your needs?

For more details, please read the README file of the sk_tunnel-0.1
release and the Documentation/networking/sk_tunnel.txt of a
patched kernel.

Henner


From owner-netdev@oss.sgi.com Sun Sep  3 10:06:04 2000
Received:  by oss.sgi.com id <S42363AbQICRFy>;
	Sun, 3 Sep 2000 10:05:54 -0700
Received: from glitch.crosswinds.net ([209.208.163.35]:41234 "EHLO
        glitch.crosswinds.net") by oss.sgi.com with ESMTP id <S42277AbQICRFa>;
	Sun, 3 Sep 2000 10:05:30 -0700
Received: from imran ([202.164.97.22])
	by glitch.crosswinds.net (8.9.3/8.9.3) with SMTP id NAA68956;
	Sun, 3 Sep 2000 13:05:20 -0400 (EDT)
	(envelope-from ipatel@crosswinds.net)
Message-ID: <001201c015c8$8b2871e0$1661a4ca@imran>
From:   "Imran Patel" <ipatel@crosswinds.net>
To:     <netdev@oss.sgi.com>
Cc:     <netfilter@us4.samba.org>
Subject: nat-pt for ipv6/ipv4
Date:   Sun, 3 Sep 2000 22:28:48 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01C015F6.540C3C40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
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_000B_01C015F6.540C3C40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hi
is there any implementation of a nat module in Linux for translation of =
an ipv6 address to ipv4 address? (rfc 2766) this is said to be =
particularly useful when there is a network of ipv6 only hosts that want =
to communicate with an ipv4 host (to access a website for example). from =
the rfc i could only get that there has to be a nat box between this =
ipv6 only network and the ipv4 internet. this nat box/router (presumably =
a dual stack m/c) will then replace the source address (ipv6 address) of =
every outbound connection with the lone public ipv4 address it possesses =
using nat/napt.=20
At present, can a router that is both on an ipv6 & ipv4 network forward =
a packet from the ipv6 network to the ipv4 network using such =
translation?

/ip

------=_NextPart_000_000B_01C015F6.540C3C40
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.2014.210" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>hi</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>is there any implementation of a nat =
module in=20
Linux for translation of an ipv6 address to ipv4 address? (rfc 2766) =
this is=20
said to be particularly useful when there is a network of ipv6 only =
hosts that=20
want to communicate with an ipv4 host (to access a website for example). =
from=20
the rfc i could only get that there has to be a nat box between this =
ipv6 only=20
network and the ipv4 internet. this nat box/router (presumably a dual =
stack m/c)=20
will then replace the source address (ipv6 address) of every outbound =
connection=20
with the lone public ipv4 address it possesses using nat/napt. =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>At present, can a&nbsp;router that is =
both on an=20
ipv6 &amp; ipv4 network&nbsp;forward&nbsp;a packet from the ipv6 network =
to the=20
ipv4 network using such translation?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>/ip</FONT></DIV></BODY></HTML>

------=_NextPart_000_000B_01C015F6.540C3C40--


From owner-netdev@oss.sgi.com Mon Sep  4 08:36:07 2000
Received:  by oss.sgi.com id <S42364AbQIDPf6>;
	Mon, 4 Sep 2000 08:35:58 -0700
Received: from glitch.crosswinds.net ([209.208.163.35]:7689 "EHLO
        glitch.crosswinds.net") by oss.sgi.com with ESMTP id <S42361AbQIDPf3>;
	Mon, 4 Sep 2000 08:35:29 -0700
Received: from imran ([202.164.97.98])
	by glitch.crosswinds.net (8.9.3/8.9.3) with SMTP id LAA94045
	for <netdev@oss.sgi.com>; Mon, 4 Sep 2000 11:34:21 -0400 (EDT)
	(envelope-from ipatel@crosswinds.net)
Message-ID: <000201c01684$fc62c740$6261a4ca@imran>
From:   "Imran Patel" <ipatel@crosswinds.net>
To:     <netdev@oss.sgi.com>
References: <001201c015c8$8b2871e0$1661a4ca@imran> <20000903191426.F7151@coruscant.sunbeam.de>
Subject: Re: nat-pt for ipv6/ipv4
Date:   Sun, 3 Sep 2000 22:56:24 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

> The Netfilter Framework is implemented seperately for each protocol stack,
> and I am not aware of any cross-stack netfilter-based modules.
that means there is no way a router can forward between an ipv4only and
ipv6only network??(maybe using something else than nat)

/ip


From owner-netdev@oss.sgi.com Tue Sep  5 10:05:46 2000
Received:  by oss.sgi.com id <S42306AbQIERF0>;
	Tue, 5 Sep 2000 10:05:26 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:18700 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42293AbQIERFJ>;
	Tue, 5 Sep 2000 10:05:09 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA30330; Tue, 5 Sep 2000 20:57:16 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200009051657.UAA30330@ms2.inr.ac.ru>
Subject: Re: nfmark routing in ip_route_output()
To:     davem@redhat.com (David S. Miller)
Date:   Tue, 5 Sep 2000 20:57:16 +0400 (MSK DST)
Cc:     rusty@linuxcare.com.au, netdev@oss.sgi.com, ges@liscon.com,
        netfilter@us4.samba.org
In-Reply-To: <14766.59187.494713.745149@pizda.ninka.net> from "David S. Miller" at Aug 31, 0 04:16:03 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 662       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Alexey can complain next week when he comes back online. :-)

Nothing to complain. 8)


BTW, Paul, we can make one interesting thing now.
Namely, something sort of setsockopt(SO_NFMARK).
After this you can override socket(2) (f.e. with LD_PRELOAD
or on application level) and select nfmark depending
on some environment variable.

The only problem is how to prevent user to override
internal nfmarks (nat). Well, and security implications are to be
analyzed. Probably, it is enough to add sysctl variable sort of
nfmark_user_mask (set to zero by default) and allow to change
nfmark via setsockopt() only if (nfmark_user_mask&nfmark) == nfmark.

Alexey

From owner-netdev@oss.sgi.com Tue Sep  5 12:21:06 2000
Received:  by oss.sgi.com id <S42413AbQIETUz>;
	Tue, 5 Sep 2000 12:20:55 -0700
Received: from ns1150.munich.netsurf.de ([195.180.235.150]:62468 "HELO
        fred.muc.de") by oss.sgi.com with SMTP id <S42293AbQIETUd>;
	Tue, 5 Sep 2000 12:20:33 -0700
Received: by fred.muc.de (Postfix, from userid 500)
	id DB782E38E0; Tue,  5 Sep 2000 21:00:21 +0200 (CEST)
Date:   Tue, 5 Sep 2000 21:00:21 +0200
From:   Andi Kleen <ak@muc.de>
To:     kuznet@ms2.inr.ac.ru
Cc:     "David S. Miller" <davem@redhat.com>, rusty@linuxcare.com.au,
        netdev@oss.sgi.com, ges@liscon.com, netfilter@us4.samba.org
Subject: Re: nfmark routing in ip_route_output()
Message-ID: <20000905210021.A8740@fred.muc.de>
References: <14766.59187.494713.745149@pizda.ninka.net> <200009051657.UAA30330@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200009051657.UAA30330@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Tue, Sep 05, 2000 at 07:31:20PM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, Sep 05, 2000 at 07:31:20PM +0200, A.N.Kuznetsov wrote:
> Hello!
> 
> > Alexey can complain next week when he comes back online. :-)
> 
> Nothing to complain. 8)
> 
> 
> BTW, Paul, we can make one interesting thing now.
> Namely, something sort of setsockopt(SO_NFMARK).
> After this you can override socket(2) (f.e. with LD_PRELOAD
> or on application level) and select nfmark depending
> on some environment variable.

I thought about something like this in the past to fix IPSec. IPSec
has to select special routes with smaller MTU to include its headers.
One idea was to use more TOS bits, the other to use a nfmark in the
socket. The problem with using the nfmark (or bits of the nfmark) 
is that it can cause collisions with other nfmark users. Adding a IPsec
TOS bit may therefore be better. 

> 
> The only problem is how to prevent user to override
> internal nfmarks (nat). Well, and security implications are to be
> analyzed. Probably, it is enough to add sysctl variable sort of
> nfmark_user_mask (set to zero by default) and allow to change
> nfmark via setsockopt() only if (nfmark_user_mask&nfmark) == nfmark.

It would be nicer if that nfmark_user_mask was part of task_struct
and would be inherited through fork, but could be only changed by root 
(or appropiate capability) 

This way you could e.g. allow certain users only limited bandwidth via
a special PAM module or an extension to pam_limits.

-Andi

-- 
This is like TV. I don't like TV.

From owner-netdev@oss.sgi.com Tue Sep  5 23:09:08 2000
Received:  by oss.sgi.com id <S42436AbQIFGIs>;
	Tue, 5 Sep 2000 23:08:48 -0700
Received: from HSE-Sudbury-ppp197360.sympatico.ca ([64.229.24.153]:7669 "EHLO
        webdata.dyndns.org") by oss.sgi.com with ESMTP id <S42305AbQIFGIV>;
	Tue, 5 Sep 2000 23:08:21 -0700
Received: from webdata.dyndns.org (bbisaill@localhost.localdomain [127.0.0.1])
	by webdata.dyndns.org (8.10.1/8.8.7) with ESMTP id e865x0p01671
	for <netdev@oss.sgi.com>; Wed, 6 Sep 2000 01:59:00 -0400
Message-ID: <39B5DD23.8C5D46DC@webdata.dyndns.org>
Date:   Wed, 06 Sep 2000 01:58:59 -0400
From:   Brian Bisaillon <bbisaill@webdata.dyndns.org>
Organization: Sault College of Applied Arts & Technology
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.4.0-test7 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev@oss.sgi.com
Subject: 2.4.0-test7: Trouble with ipchains (2.2-style) support
Content-Type: multipart/mixed;
 boundary="------------241606F8FDEBB9E2C94D11C3"
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.
--------------241606F8FDEBB9E2C94D11C3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm having trouble with linux kernel 2.4.0-test7 reguarding the
Networking
Options / IP: Netfilter Configuration / ipchains (2.2-style) support.
Here is
what I am experiencing:

First of all I have a Linux Router setup with Red Hat 6.2 and it has two

Ethernet interfaces. eth0 is responsible for internal traffic and eth1
is
connected to the ADSL modem. I basically start a normal PPPoE session
and my
ppp0 interface goes up perfectly. I have an IPCHAINS firewall script
that
allows me to masquerade connections to allow clients behind the firewall
to
access the Internet via allowed ports. I've tried PMFirewall from
www.pointman.org and I've tried a firewall.sh script (that I am using
now)
that I picked up from freshmeat.net.

Problems:

1) When using a linux client behind the firewall, I can browse to
www1.sympatico.ca using lynx no problem. However, when I use Netscape it
says
it's Transferring data from the site but nothing happens. It just sits
there.
This happens only for certain sites. For example, I've experienced it
for
www1.sympatico.ca, and www.sierra.com. Other sites like altavista.com
etc.
will work fine. This same problem happens from a Windows client. I can
see
some websites fine with a browser but with others I can't unless I
browse
directly from the firewall box or I use lynx on a linux client.

2) When trying to browse ftp sites I kept having odd port errors. I
noticed
an option in Internet Explorer that led me to believe I had to use
passive
mode transfer so I enabled the option and it worked no problem.

3) When I try to irc to efnet, it connects, authenticates via identd
thanks
to midentd on the firewall box, but just before it goes to display an
motd
message it hangs there and I can't do anything even though I'm online.
For
example, I'll try to join a channel and nothing happens. This happened
to me
in mIRC from a windows client and BitchX (modded ircii by panasync) for
Linux. However, I can go on Undernet and Dalnet just fine without any
problems. Ident works fine and even for efnet it worked fine but for
some
reason I can't get on efnet from clients behind the firewall. If I use
the
firewall box I can get on efnet no problem.

I think this is a problem reguarding the backwards compatibility code
for
IPCHAINS in 2.4.0-test7. I've tried different IPCHAINS scripts and I had
the
same problems. I've tried windows clients and linux clients (two
completely
different platforms running different programs) and the same problems
arose.
I was wondering if you have any solutions to my problem?

Here's some more information in case you need it:

eth0 - 192.168.1.1 - Used as default Gateway for clients (this is on a
10/100Mbps switch)

eth1 - 192.168.1.2 - Used to transfer data to/from ADSL modem (this is
connected directly to the ADSL modem)

ppp0 - This interface gets put up once a successful PPPoE session has
been
negotiated via Bell's Sympatico High Speed Edition ADSL service.

I have attached the current firewall script I am using now to give you
an
indication on how my firewall is currently setup. I use this command:

./firewall.sh ppp0 eth0

----------------------------------------
Brian Bisaillon <bbisaillon@pmail.net>
Website: http://webdata.dyndns.org
Computer Network Technology Student
Sault College of Applied Arts & Technology
---------------------------------------

--------------241606F8FDEBB9E2C94D11C3
Content-Type: application/x-sh;
 name="firewall.sh"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="firewall.sh"

#!/bin/bash
#
# IPCHAINS-FIREWALL V1.7.0
# April 30th, 2000

# -------------------------------------------------- Ipchains Firewall Script -

# Original script by Ian Hall-Beyer (manuka@nerdherd.net)
#
# Contributors:
#
# 1.5
# terminus (cpm@dotquad.com) (ICQ & DHCP, @home testing)
#
# 1.7
# Emannuel Paré (emman@voxtel.com) (timeout values)
# Bill Mote (bill.mote@bigfoot.com) (testing)
#
# ------------------------------------------------------------- Configuration -

# Set the location of the ipchains and ifconfig binaries

IPCHAINS="/sbin/ipchains"
IFCONFIG="/sbin/ifconfig"

# ---------------------------------------------------------------- Interfaces -

if [ $# -lt 1 ];
 then
  echo "Syntax: $0 <external interface> [internal interface]"
  exit
 elif [ $# = 1 ];
  then
   EXTERNALIF=$1
   INTERNALIF="none"
 else
   EXTERNALIF=$1
   INTERNALIF=$2
fi


# ------------------------------------------------------------ Grok Addresses -

function grok_interface {
if [ ! -z "`ifconfig $1 2>/dev/null | grep UP`" ];
 then 
  echo "1" 
 else 
  echo "0"
fi
}

function grok_address {
  IP=`$IFCONFIG $1 2>/dev/null| grep inet | cut -d : -f 2 | cut -d \  -f 1`
  MASK=`$IFCONFIG $1 2>/dev/null| grep Mask | cut -d : -f 4`
  NET=`route -n | grep eth0 | grep "255.255.255.224" | grep -w "U" | cut -d\  -f1`
  echo "$IP/$MASK"
}

function grok_net {
  MASK=`$IFCONFIG $1 2>/dev/null| grep Mask | cut -d : -f 4`
  NET=`route -n | grep $1 | grep $MASK | grep -w "U" | cut -d\  -f1`
  echo "$NET/$MASK"

}

echo -n "Checking External Interface..."

if [ "`grok_interface $EXTERNALIF`" != "1" ];
 then 
  echo "$EXTERNALIF unavailable. Aborting."
  exit
 else 
  echo "found $EXTERNALIF"
  echo "External Interface Data:"
  echo "Address: `grok_address $EXTERNALIF`"
  echo "Network: `grok_net $EXTERNALIF`"
fi

echo -n "Checking Internal Interface..."

if [ "$INTERNALIF" = "none" ];
  then
     STANDALONE="1"
     echo "None specified"
     echo "Going to Standalone Mode"                 
  else                      
   if [ "`grok_interface $INTERNALIF`" != "1" ];
    then 
     echo "$INTERNALIF unavailable."
     echo "Going to Standalone Mode"
     STANDALONE="1"
    else
     echo "found $INTERNALIF"
     echo "Internal Interface Data:"
     echo "Address: `grok_address $INTERNALIF`"
     echo "Network: `grok_net $INTERNALIF`"
     STANDALONE="0"
   fi
fi

if [ "$STANDALONE" = "0" ];
  then                                                                               echo -n "Checking internal interface for RFC1918"
     declare -i DOTQUAD1                                                                     
     declare -i DOTQUAD2                                                                     

     DOTQUAD1=`grok_net $INTERNALIF | cut -f1 -d.`                                              
     DOTQUAD2=`grok_net $INTERNALIF | cut -f2 -d.`                                              
     
     if [ "$DOTQUAD1" = "10" ]; then                                  
         MASQUERADE="1"
         echo "Class A found"      
         echo "Going to Masq Mode"
      elif [ "$DOTQUAD1" = "192" -a "$DOTQUAD2" = "168" ]; then          
         MASQUERADE="1" 
         echo "Class C found"
         echo "Going to Masq Mode"
      elif [ "$DOTQUAD1" = "172" -a $DOTQUAD2 -gt 15 -a $DOTQUAD2 -lt 32 ]; then
         MASQUERADE="1" 
         echo "Class B found"
         echo "Going to Masq Mode"
      else
         echo "None found"
         echo "Going to Routable Mode"
         MASQUERADE="0"
     fi
fi                                                                                           

function flush_rulesets {

# No parameters

echo -n "Flushing rulesets.."

# Incoming packets from the outside network
$IPCHAINS -F input
echo -n "."

# Outgoing packets from the internal network
$IPCHAINS -F output   
echo -n "."

# Forwarding/masquerading
$IPCHAINS -F forward
echo -n "."

echo "Done!"
}

function masq_setup {

# Parameters: internalnet, externalnet

echo -n "Masquerading.."

# don't masquerade internal-internal traffic
$IPCHAINS -A forward -s $1 -d $1 -j ACCEPT
echo -n "."

# don't Masquerade external interface direct
$IPCHAINS -A forward -s $2 -d 0/0 -j ACCEPT 
echo -n "."

# masquerade all internal IP's going outside
$IPCHAINS -A forward -s $1 -d 0/0 -j MASQ

echo -n "."

# set Default rule on forward chain to Deny
$IPCHAINS -P forward DENY
echo -n "."
}

function routable_setup {

# Parameters: internalnet, externalnet

echo -n "Forwarding.."

# Forward internal-internal traffic
$IPCHAINS -A forward -s $1 -d $1 -j ACCEPT
echo -n "."

# Forward external interface direct
$IPCHAINS -A forward -s $2 -d $0/0 -j ACCEPT 
echo -n "."

# Forward internal network going outside
$IPCHAINS -A forward -s $1 -d $1 -j ACCEPT
echo -n "."

# Forward external network going inside    
$IPCHAINS -A forward -s $2 -d $1 -j ACCEPT
echo -n "."

echo "Done!"

}


function loopback {

# Parameters: No parameters

echo -n "Loopback..."

$IPCHAINS -A input -i lo -s 0/0 -d 0/0 -j ACCEPT
$IPCHAINS -A output -i lo -s 0/0 -d 0/0 -j ACCEPT
echo "Done!"

}

function tos_setup {

# Parameters: No parameters

echo -n "TOS flags.."

$IPCHAINS -A output -p tcp -d 0/0 www -t 0x01 0x10
$IPCHAINS -A output -p tcp -d 0/0 telnet -t 0x01 0x10   
$IPCHAINS -A output -p tcp -d 0/0 ftp -t 0x01 0x10
echo -n "..."

# Set ftp-data for maximum throughput
$IPCHAINS -A output -p tcp -d 0/0 ftp-data -t 0x01 0x08
echo -n "."

echo "Done!"

}

function outbound_setup {

# Parameters: internalnet

echo -n "Outbound connections.."
$IPCHAINS -A input -s $1 -d 0/0 -j ACCEPT   
$IPCHAINS -A output -s $1 -d 0/0 -j ACCEPT
echo -n ".."

echo "Done!"

}

function standard_rules {

# Parameters: target, standalone, internalif

# ---------------------------------------------------------- Trusted Networks -
# Add in any rules to specifically allow connections from hosts/nets that
# would otherwise be blocked.

echo -n "Trusted Networks.."

# Sympatico Servers
$IPCHAINS -A input -p tcp -s 204.101.251.0/24 -d $1 1023:65535 -j ACCEPT
echo -n "."

# Sympatico Routers
$IPCHAINS -A input -p tcp -s 206.108.99.0/24 -d $1 1023:65535 -j ACCEPT 
echo -n "."

echo "Done!"

# ----------------------------------------------------------- Banned Networks -
# Add in any rules to specifically block connections from hosts/nets that
# have been known to cause you problems. These packets are logged.

# echo -n "Banned Networks.."

# This one is generic
# $IPCHAINS -A input -l -s [banned host/net] -d $1 <ports> -j DENY
# echo -n "."

# This one blocks ICMP attacks
# $IPCHAINS -A input -l -b -i $LOCALIF -p icmp -s [host/net] -d $1 -j DENY
# echo -n "."

# echo "Done!"

# ------------------------------------------------------ @home-specific rules -
# This @home stuff is pretty specific to me (terminus).  I get massive port
# scans from my neighbors and from pokey admins at @home, so I just got harsh
# and blocked all their stuff, with a few exceptions, listed below.
#
# If someone out there finds out the ip ranges of JUST tci@home, let me know
# so i don't end up blocking ALL cablemodems like it's doing now.

echo -n "Cable Modem Nets.."

# so we can check mail, use the proxy server, hit @home's webpage.
# you will want to set these to your local servers, and uncomment them

# $IPCHAINS -A input -p tcp -s ha1.rdc1.wa.home.com -d $1 1023:65535 -j ACCEPT
# $IPCHAINS -A input -p tcp -s mail.tcma1.wa.home.com -d $1 1023:65535 -j ACCEPT
# $IPCHAINS -A input -p tcp -s www.tcma1.wa.home.com -d $1 1023:65355 -j ACCEPT
# $IPCHAINS -A input -p tcp -s proxy.tcma1.wa.home.com -d $1 1023:65535  -j ACCEPT
# echo -n "...."

# so we can resolve the above hostnames, allow dns queries back to us
# $IPCHAINS -A input -p tcp -s ns1.home.net -d $1 1023:65535 -j ACCEPT
# $IPCHAINS -A input -p tcp -s ns2.home.net -d $1 1023:65535 -j ACCEPT
# $IPCHAINS -A input -p udp -s ns1.home.net -d $1 1023:65535 -j ACCEPT
# $IPCHAINS -A input -p udp -s ns2.home.net -d $1 1023:65535 -j ACCEPT
# echo -n ".."

# linux ipchains building script page (I think)
# $IPCHAINS -A input -p tcp -s 24.128.61.117 -d $1 1023:65535 -j  ACCEPT
# echo -n "."

# Non-@home users may want to leave this uncommented, just to block all
# the wannabe crackers. Add any @home hosts you want to allow BEFORE this line.

# Blast all other @home connections into infinity and log them.
# $IPCHAINS -A input -l -s 24.0.0.0/8 -d $1 -j DENY
# echo -n "."

# Nuke any connections from @home's portscanners (ops-scan.home.com)
$IPCHAINS -A input -l -s 24.0.84.130 -d $1 -j DENY
echo -n "."

echo "Done!"

# ---------------------------- Specific port blocks on the external interface -
# This section blocks off ports/services to the outside that have
# vulnerabilities. This will not affect the ability to use these services
# within your network. 

echo -n "Port Blocks.."
 
# NetBEUI/Samba
#$IPCHAINS -A input -p tcp -s 0/0 -d $1 137:139 -j DENY
#$IPCHAINS -A input -p udp -s 0/0 -d $1 137:139 -j DENY
#echo -n "."

# Microsoft SQL
$IPCHAINS -A input -p tcp -s 0/0 -d $1 1433 -j DENY
$IPCHAINS -A input -p udp -s 0/0 -d $1 1433 -j DENY
echo -n "."

# Postgres SQL

$IPCHAINS -A input -p tcp -s 0/0 -d $1 5432 -j DENY
$IPCHAINS -A input -p udp -s 0/0 -d $1 5432 -j DENY
echo -n "."

# Network File System
$IPCHAINS -A input -p tcp -s 0/0 -d $1 2049 -j DENY
$IPCHAINS -A input -p udp -s 0/0 -d $1 2049 -j DENY
echo -n "."

# MySQL
$IPCHAINS -A input -p tcp -s 0/0 -d $1 3306 -j DENY
$IPCHAINS -A input -p udp -s 0/0 -d $1 3306 -j DENY
echo -n "."

# X Displays
$IPCHAINS -A input -p tcp -s 0/0 -d $1 5999:6010 -j DENY
$IPCHAINS -A input -p udp -s 0/0 -d $1 5999:6010 -j DENY
echo -n "."

# X Font Server :0-:2-
$IPCHAINS -A input -p tcp -s 0/0 -d $1 7100 -j DENY
$IPCHAINS -A input -p udp -s 0/0 -d $1 7100 -j DENY
echo -n "."

# Back Orifice (logged)
$IPCHAINS -A input -l -p tcp -s 0/0 -d $1 31337 -j DENY
$IPCHAINS -A input -l -p udp -s 0/0 -d $1 31337 -j DENY
echo -n "."

# NetBus (logged)
$IPCHAINS -A input -l -p tcp -s 0/0 -d $1 12345:12346 -j DENY
$IPCHAINS -A input -l -p udp -s 0/0 -d $1 12345:12346 -j DENY
echo -n "."

echo "Done!"

# --------------------------------------------------- High Unprivileged ports -
# These are opened up to allow sockets created by connections allowed by 
# ipchains

echo -n "High Ports.."

$IPCHAINS -A input -p tcp -s 0/0 -d $1 1023:65535 -j ACCEPT
$IPCHAINS -A input -p udp -s 0/0 -d $1 1023:65535 -j ACCEPT
echo -n "."

echo "Done!"

# ------------------------------------------------------------ Basic Services -

echo -n "Services.."

# ftp-data (20) and ftp (21)
$IPCHAINS -A input -p tcp -s 0/0 -d $1 20 -j ACCEPT
$IPCHAINS -A input -p tcp -s 0/0 -d $1 21 -j ACCEPT
#echo -n ".."

# ssh (22)
#$IPCHAINS -A input -p tcp -s 0/0 -d $1 22 -j ACCEPT
#echo -n "."

# telnet (23)
$IPCHAINS -A input -p tcp -s 0/0 -d $1 23 -j ACCEPT
echo -n "."

# smtp (25)
$IPCHAINS -A input -p tcp -s 0/0 -d $1 25 -j ACCEPT
echo -n "."

# DNS (53)
$IPCHAINS -A input -p tcp -s 0/0 -d $1 53 -j ACCEPT
$IPCHAINS -A input -p udp -s 0/0 -d $1 53 -j ACCEPT
echo -n ".."

if [ "$2" != "1" ]; then
  # DHCP on LAN side (to make @Home DHCP work) (67/68)
  $IPCHAINS -A input -i $3 -p udp -s 0/0 -d 255.255.255.255/24 67 -j ACCEPT
  $IPCHAINS -A output -i $3 -p udp -s 0/0 -d 255.255.255.255/24 68 -j ACCEPT
echo -n ".."
fi

# http (80)
$IPCHAINS -A input -p tcp -s 0/0 -d $1 80 -j ACCEPT
echo -n "."

# POP-3 (110)
$IPCHAINS -A input -p tcp -s 0/0 -d $1 110 -j ACCEPT
echo -n "."

# identd (113)
$IPCHAINS -A input -p tcp -s 0/0 -d $1 113 -j ACCEPT
echo -n "."

# nntp (119)
$IPCHAINS -A input -p tcp -s 0/0 -d $1 119 -j ACCEPT
echo -n "."

# https (443)
$IPCHAINS -A input -p tcp -s 0/0 -d $1 443 -j ACCEPT
echo -n "."

# ICQ Services (it's a server service) (4000)
#$IPCHAINS -A input -p tcp -s 0/0 -d $1 4000 -j ACCEPT
#echo -n "."

echo "Done!"

# ---------------------------------------------------------------------- ICMP -

echo -n "ICMP Rules.."

# Use this to deny ICMP attacks from specific addresses
# $IPCHAINS -A input -b -i $EXTERNALIF -p icmp -s <address> -d 0/0 -j DENY
# echo -n "."

# Allow incoming ICMP
$IPCHAINS -A input -p icmp -s 0/0 -d $1 -j ACCEPT
$IPCHAINS -A input -p icmp -s 0/0 -d $1 -j ACCEPT
echo -n ".."

# Allow outgoing ICMP
$IPCHAINS -A output -p icmp -s $1 -d 0/0 -j ACCEPT
$IPCHAINS -A output -p icmp -s $1 -d 0/0 -j ACCEPT
echo -n "...."

echo "Done!"

}

function set_policy {

# Parameters: no parameters

$IPCHAINS -A input -j DENY
$IPCHAINS -A output -j ACCEPT

}

function set_timeouts {

# Parameters: no parameters

echo -n "Setting Ipchains timeout for tcp tcpfin udp.. "                              
$IPCHAINS -M -S 3600 150 1000                                                      
echo "Done!"                                                                  

}

flush_rulesets

if [ "$STANDALONE" = "1" ];
 then 
  TARGET=`grok_net $EXTERNALIF`
 else
  if [ "$MASQUERADE" = "1" ];
   then
    TARGET=`grok_address $EXTERNALIF`
    INTERNALNET=`grok_net $INTERNALIF`
    EXTERNALNET=`grok_net $EXTERNALIF`
    outbound_setup $INTERNALNET
    set_timeouts
    masq_setup $INTERNALNET $TARGET
   else
    TARGET=`grok_net $INTERNALIF`
    INTERNALNET=`grok_net $INTERNALIF`
    EXTERNALNET=`grok_net $EXTERNALIF`
    outbound_setup $INTERNALNET
    routable_setup $INTERNALNET $EXTERNALNET
  fi
fi

tos_setup
loopback
standard_rules $TARGET $STANDALONE $INTERNALIF
#configure_vpn $INTERNALNET $EXTERNALNET 
set_policy

--------------241606F8FDEBB9E2C94D11C3--


From owner-netdev@oss.sgi.com Thu Sep  7 04:38:36 2000
Received:  by oss.sgi.com id <S42186AbQIGLiQ>;
	Thu, 7 Sep 2000 04:38:16 -0700
Received: from natmail2.webmailer.de ([192.67.198.65]:52208 "EHLO
        post.webmailer.de") by oss.sgi.com with ESMTP id <S42183AbQIGLiE>;
	Thu, 7 Sep 2000 04:38:04 -0700
Received: from frog.athome (pec-107-201.tnt6.s2.uunet.de [149.225.107.201])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id NAA14994;
	Thu, 7 Sep 2000 13:37:53 +0200 (MET DST)
Received: from localhost (hgfelger@localhost)
	by frog.athome (8.9.3/8.9.3) with ESMTP id NAA09015;
	Thu, 7 Sep 2000 13:38:18 +0200
X-Authentication-Warning: frog.athome: hgfelger owned process doing -bs
Date:   Thu, 7 Sep 2000 13:38:12 +0200 (CEST)
From:   Hartwig Felger <hgfelger@hgfelger.de>
X-Sender: hgfelger@frog.athome
Reply-To: hgfelger@hgfelger.de
To:     netdev@oss.sgi.com
cc:     mostrows@styx.uwaterloo.ca
Subject: dsl masquerading over linux 2.4.0-test[78]pre...
Message-ID: <Pine.LNX.4.10.10009071327070.8933-100000@frog.athome>
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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salut,
I got a setup, where I can surf from the box, where the ADSL is installed.
This box also has ISDN and Modem connected. It offers via
iptables-masquerading its internet-connection to other boxes in the lan.
This works for ISDN as well as for modem... But with dsl it makes
problems:
If I change the mru I can do ftp-downloads with lynx, but with netscape I
can not get the whole start-page of www.adobe.com (just for example - it
also does not work with other sites). When I start netscape on the server
itself, it works as espected. So it seams, that iptables-masqerading
triggers a bug in pppoe, or has a bug that is triggered by pppoe.

Please give me an advice, how to narrow the problem...

Thanks hartwig

Linux 2.4.0-test8-4 and test7-rel
iptables v1.1.1
pppd-2.4.0 with ppp-2.4.0-pppoe.patch1
- -- 
1024D/339FD693 Hartwig Felger <hgfelger@hgfelger.de>
Key fingerprint = FB2F 3EE9 345A D55B 6FF2  0EC1 F5B0 684F 339F D693
For the pulic keys, please visit my page.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5t34q9bBoTzOf1pMRAi0XAKC8zESpAz4C6+9utSx8uVhiiXIe2ACbBEKN
yrfmV+aCWKrjRE1tD3L0xAA=
=5xK5
-----END PGP SIGNATURE-----


From owner-netdev@oss.sgi.com Thu Sep  7 05:07:07 2000
Received:  by oss.sgi.com id <S42188AbQIGMG4>;
	Thu, 7 Sep 2000 05:06:56 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:1742 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42183AbQIGMGl>;
	Thu, 7 Sep 2000 05:06:41 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA29347;
	Thu, 7 Sep 2000 08:06:34 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id IAA00973;
	Thu, 7 Sep 2000 08:06:34 -0400 (EDT)
Date:   Thu, 7 Sep 2000 08:06:34 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Hartwig Felger <hgfelger@hgfelger.de>
cc:     netdev@oss.sgi.com, mostrows@styx.uwaterloo.ca
Subject: Re: dsl masquerading over linux 2.4.0-test[78]pre...
In-Reply-To: <Pine.LNX.4.10.10009071327070.8933-100000@frog.athome>
Message-ID: <Pine.GSO.4.20.0009070803220.949-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 Thu, 7 Sep 2000, Hartwig Felger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Salut,
> I got a setup, where I can surf from the box, where the ADSL is installed.
> This box also has ISDN and Modem connected. It offers via
> iptables-masquerading its internet-connection to other boxes in the lan.
> This works for ISDN as well as for modem... But with dsl it makes
> problems:
> If I change the mru I can do ftp-downloads with lynx, but with netscape I
> can not get the whole start-page of www.adobe.com (just for example - it
> also does not work with other sites). When I start netscape on the server
> itself, it works as espected. So it seams, that iptables-masqerading
> triggers a bug in pppoe, or has a bug that is triggered by pppoe.
> 
> Please give me an advice, how to narrow the problem...
> 

I think your problems are path-mtu related.

Please try Marc Boucher's mssclampfw packaged in the contrib directory
in the pppoed-047 package at:

http://www.davin.ottawa.on.ca/pppoe

Note do not use anything else from that package for 2.4 all you need is
contrib/mssclampfw

cheers,
jamal


From owner-netdev@oss.sgi.com Thu Sep  7 09:41:48 2000
Received:  by oss.sgi.com id <S42197AbQIGQl1>;
	Thu, 7 Sep 2000 09:41:27 -0700
Received: from raven.ecs.soton.ac.uk ([152.78.70.1]:20963 "EHLO
        raven.ecs.soton.ac.uk") by oss.sgi.com with ESMTP id <S42192AbQIGQk7>;
	Thu, 7 Sep 2000 09:40:59 -0700
Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135])
	by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA03282
	for <netdev@oss.sgi.com>; Thu, 7 Sep 2000 17:40:56 +0100 (BST)
Received: from daffy.ecs.soton.ac.uk (IDENT:de@daffy.ecs.soton.ac.uk [152.78.65.214])
	by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id RAA26553
	for <netdev@oss.sgi.com>; Thu, 7 Sep 2000 17:40:54 +0100 (BST)
Date:   Thu, 7 Sep 2000 17:41:59 +0100 (BST)
From:   Daniel Elphick <de@ecs.soton.ac.uk>
X-Sender: de@localhost.localdomain
To:     netdev@oss.sgi.com
Subject: IPv6 Router Alert in Linux 2.2.x
Message-ID: <Pine.LNX.4.21.0009071734120.972-100000@localhost.localdomain>
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


Is there any chance that the definition for IPV6_TLV_ROUTERALERT, which
is misdefined in the 2.2 kernel yet fixed in 2.4.x, will also be fixed in
the 2.2 kernel?

A simple patch would be :

--- /usr/src/linux/include/linux/in6.h	Mon Aug  9 20:05:13 1999
+++ /home/de/in6.h	Thu Sep  7 16:40:55 2000
@@ -138,7 +138,7 @@
  */
 #define IPV6_TLV_PAD0		0
 #define IPV6_TLV_PADN		1
-#define IPV6_TLV_ROUTERALERT	20
+#define IPV6_TLV_ROUTERALERT	5
 #define IPV6_TLV_JUMBO		194
 
 /*


Cheers,
Dan


From owner-netdev@oss.sgi.com Thu Sep  7 11:15:28 2000
Received:  by oss.sgi.com id <S42201AbQIGSPS>;
	Thu, 7 Sep 2000 11:15:18 -0700
Received: from HSE-MTL-ppp64517.qc.sympatico.ca ([64.229.169.200]:39899 "EHLO
        opium.mbsi.ca") by oss.sgi.com with ESMTP id <S42192AbQIGSOv>;
	Thu, 7 Sep 2000 11:14:51 -0700
Received: from opium.mbsi.ca (marc@localhost [127.0.0.1])
	by opium.mbsi.ca (8.11.0/8.11.0) with ESMTP id e87IEfA06978;
	Thu, 7 Sep 2000 14:14:41 -0400 (EDT)
Message-Id: <200009071814.e87IEfA06978@opium.mbsi.ca>
X-Mailer: exmh version 2.2 07/04/2000 with nmh-1.0.4+dev
To:     jamal <hadi@cyberus.ca>
Subject: Re: dsl masquerading over linux 2.4.0-test[78]pre...
Cc:     netdev@oss.sgi.com, mostrows@styx.uwaterloo.ca,
        hgfelger@hgfelger.de, rusty@linuxcare.com.au,
        netfilter-devel@us4.samba.org
In-Reply-To: Your message of "Thu, 07 Sep 2000 08:06:34 EDT."
             <Pine.GSO.4.20.0009070803220.949-100000@shell.cyberus.ca> 
References: <Pine.GSO.4.20.0009070803220.949-100000@shell.cyberus.ca> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 07 Sep 2000 14:14:40 -0400
From:   Marc Boucher <marc@mbsi.ca>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


As Jamal says, mssclampfw can do the trick but since you are already
using iptables installed I would recommand its TCPMSS match&target
modules instead. These are in the tcp-MSS patch which can be found under
netfilter/userspace/patch-o-matic/ (in the CVS repository, or next
upcoming iptables release > 1.1.1). Use the ./runme script in that same
directory to apply it, then recompile iptables and reconfigure/rebuild
your kernel with CONFIG_IP_NF_MATCH_TCPMSS and
CONFIG_IP_NF_TARGET_TCPMSS enabled.

Then you need a rule like:

iptables -t nat -A POSTROUTING -o pppoe_interface \
    -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss mtuofpppoeintf-40+1: \
    -j TCPMSS --set-mss mtuofpppoeintf-40

so for example if the outgoing PPPoE interface is ppp0 with an mtu of 
1492, you would have:

iptables -t nat -A POSTROUTING -o ppp0 \
    -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1453: \
    -j TCPMSS --set-mss 1452

Replacing "-t nat -A POSTROUTING" with "-A FORWARD" should also work.

Before Rusty mentions that the nat&filter tables weren't meant for this
kind of stuff, let me admit that it would be conceptually neater to put
such a rule in the 'mangle' table but unfortunately the latter only has
PREROUTING and OUTPUT hooks at this time. At the PREROUTING stage the
output interface isn't known so you couldn't select packets based on
that, and the OUTPUT chain only sees packets originating from the
gateway itself.

Rusty, what would you think of adding the missing hooks to the 'mangle'
table; extending its purpose to general packet alteration, not just
changing stuff that influences routing?

I am also considering implementing a --clamp-mss-to-mtu option to the
TCPMSS extension target that would, like mssclampfw did, automatically
calculate the maximum value based on the outgoing interfaces' MTU and if
necessary adjust the packet's option value. So users would only need a
rule like:

iptables -t mangle -A POSTROUTING [-o intf] -p tcp --tcp-flags SYN,RST SYN \
	-j TCPMSS --clamp-mss-to-mtu

Opinions?

Cheers,
Marc

> 
> On Thu, 7 Sep 2000, Hartwig Felger wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Salut,
> > I got a setup, where I can surf from the box, where the ADSL is installed.
> > This box also has ISDN and Modem connected. It offers via
> > iptables-masquerading its internet-connection to other boxes in the lan.
> > This works for ISDN as well as for modem... But with dsl it makes
> > problems:
> > If I change the mru I can do ftp-downloads with lynx, but with netscape I
> > can not get the whole start-page of www.adobe.com (just for example - it
> > also does not work with other sites). When I start netscape on the server
> > itself, it works as espected. So it seams, that iptables-masqerading
> > triggers a bug in pppoe, or has a bug that is triggered by pppoe.
> > 
> > Please give me an advice, how to narrow the problem...
> > 
> 
> I think your problems are path-mtu related.
> 
> Please try Marc Boucher's mssclampfw packaged in the contrib directory
> in the pppoed-047 package at:
> 
> http://www.davin.ottawa.on.ca/pppoe
> 
> Note do not use anything else from that package for 2.4 all you need is
> contrib/mssclampfw
> 
> cheers,
> jamal
> 



From owner-netdev@oss.sgi.com Thu Sep  7 12:06:38 2000
Received:  by oss.sgi.com id <S42208AbQIGTG3>;
	Thu, 7 Sep 2000 12:06:29 -0700
Received: from HSE-MTL-ppp64517.qc.sympatico.ca ([64.229.169.200]:25308 "EHLO
        opium.mbsi.ca") by oss.sgi.com with ESMTP id <S42205AbQIGTGN>;
	Thu, 7 Sep 2000 12:06:13 -0700
Received: from opium.mbsi.ca (marc@localhost [127.0.0.1])
	by opium.mbsi.ca (8.11.0/8.11.0) with ESMTP id e87J64g07611;
	Thu, 7 Sep 2000 15:06:04 -0400 (EDT)
Message-Id: <200009071906.e87J64g07611@opium.mbsi.ca>
X-Mailer: exmh version 2.2 07/04/2000 with nmh-1.0.4+dev
To:     jamal <hadi@cyberus.ca>, netdev@oss.sgi.com,
        mostrows@styx.uwaterloo.ca, hgfelger@hgfelger.de,
        rusty@linuxcare.com.au, netfilter-devel@us4.samba.org
Subject: Re: dsl masquerading over linux 2.4.0-test[78]pre... 
In-Reply-To: Your message of "Thu, 07 Sep 2000 14:14:40 EDT."
             <200009071814.e87IEfA06978@opium.mbsi.ca> 
References: <Pine.GSO.4.20.0009070803220.949-100000@shell.cyberus.ca>  <200009071814.e87IEfA06978@opium.mbsi.ca> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 07 Sep 2000 15:06:04 -0400
From:   Marc Boucher <marc@mbsi.ca>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Earlier I wrote:
> 
> As Jamal says, mssclampfw can do the trick but since you are already
> using iptables installed I would recommend its TCPMSS match&target
> modules instead. These are in the tcp-MSS patch which can be found under
> netfilter/userspace/patch-o-matic/ (in the CVS repository, or next
> upcoming iptables release > 1.1.1). Use the ./runme script in that same
> directory to apply it, then recompile iptables and reconfigure/rebuild
> your kernel with CONFIG_IP_NF_MATCH_TCPMSS and
> CONFIG_IP_NF_TARGET_TCPMSS enabled.
> 
> Then you need a rule like:
> 
> iptables -t nat -A POSTROUTING -o pppoe_interface \
>     -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss mtuofpppoeintf-40+1: \
>     -j TCPMSS --set-mss mtuofpppoeintf-40
> 
> so for example if the outgoing PPPoE interface is ppp0 with an mtu of 
> 1492, you would have:
> 
> iptables -t nat -A POSTROUTING -o ppp0 \
>     -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1453: \
>     -j TCPMSS --set-mss 1452
> 
> Replacing "-t nat -A POSTROUTING" with "-A FORWARD" should also work.

Actually it will work better with "-A FORWARD", since the nat table
apparently doesn't "see" SYN ACK packets, whose MSS also needs to be
adjusted in the case of incoming connections relayed to hosts behind the
firewall with DNAT..

Marc



From owner-netdev@oss.sgi.com Thu Sep  7 16:06:51 2000
Received:  by oss.sgi.com id <S42226AbQIGXGb>;
	Thu, 7 Sep 2000 16:06:31 -0700
Received: from pizda.ninka.net ([216.101.162.242]:49027 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42205AbQIGXGN>;
	Thu, 7 Sep 2000 16:06:13 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id PAA06607;
	Thu, 7 Sep 2000 15:53:58 -0700
Date:   Thu, 7 Sep 2000 15:53:58 -0700
Message-Id: <200009072253.PAA06607@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     de@ecs.soton.ac.uk
CC:     netdev@oss.sgi.com
In-reply-to: <Pine.LNX.4.21.0009071734120.972-100000@localhost.localdomain>
	(message from Daniel Elphick on Thu, 7 Sep 2000 17:41:59 +0100 (BST))
Subject: Re: IPv6 Router Alert in Linux 2.2.x
References:  <Pine.LNX.4.21.0009071734120.972-100000@localhost.localdomain>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date:   Thu, 7 Sep 2000 17:41:59 +0100 (BST)
   From: Daniel Elphick <de@ecs.soton.ac.uk>

   Is there any chance that the definition for IPV6_TLV_ROUTERALERT,
   which is misdefined in the 2.2 kernel yet fixed in 2.4.x, will also
   be fixed in the 2.2 kernel?

Thanks, I've put this into my tree and sent it off to Alan.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Sat Sep  9 21:27:54 2000
Received:  by oss.sgi.com id <S42309AbQIJE1e>;
	Sat, 9 Sep 2000 21:27:34 -0700
Received: from dialup-ad-10-11.camtech.net.au ([203.28.1.139]:35340 "HELO
        halfway.linuxcare.com.au") by oss.sgi.com with SMTP
	id <S42297AbQIJE1O>; Sat, 9 Sep 2000 21:27:14 -0700
Received: from linuxcare.com.au (localhost [127.0.0.1])
	by halfway.linuxcare.com.au (Postfix) with ESMTP
	id 0F0B8813A; Fri,  8 Sep 2000 11:52:47 +1100 (EST)
From:   Rusty Russell <rusty@linuxcare.com.au>
To:     kuznet@ms2.inr.ac.ru
Cc:     netdev@oss.sgi.com, netfilter@us4.samba.org
Subject: Re: nfmark routing in ip_route_output() 
In-reply-to: Your message of "Tue, 05 Sep 2000 20:57:16 +0400."
             <200009051657.UAA30330@ms2.inr.ac.ru> 
Date:   Fri, 08 Sep 2000 11:52:47 +1100
Message-Id: <20000908005249.0F0B8813A@halfway.linuxcare.com.au>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In message <200009051657.UAA30330@ms2.inr.ac.ru> you write:
> Hello!

Hi Alexey!

> BTW, Paul, we can make one interesting thing now.
> Namely, something sort of setsockopt(SO_NFMARK).

There are so many approaches, and I'm not clever enough to know which
is right: for user rate limiting we have the iptables `owner' match,
but it's fooled by setuid like ping; Andi's idea would make it
reliable.  Your idea would be useful maybe for some other stuff.

So I'll wait until someone has a need, and then they can read these
archives, then write a patch how they prefer. 8)

Cheers,
Rusty.
--
Hacking time.

From owner-netdev@oss.sgi.com Sat Sep  9 21:27:55 2000
Received:  by oss.sgi.com id <S42297AbQIJE1o>;
	Sat, 9 Sep 2000 21:27:44 -0700
Received: from dialup-ad-10-11.camtech.net.au ([203.28.1.139]:33804 "HELO
        halfway.linuxcare.com.au") by oss.sgi.com with SMTP
	id <S42304AbQIJE1T>; Sat, 9 Sep 2000 21:27:19 -0700
Received: from linuxcare.com.au (localhost [127.0.0.1])
	by halfway.linuxcare.com.au (Postfix) with ESMTP
	id 8BE92813C; Fri,  8 Sep 2000 12:33:14 +1100 (EST)
From:   Rusty Russell <rusty@linuxcare.com.au>
To:     Brian Bisaillon <bbisaill@webdata.dyndns.org>
Cc:     netdev@oss.sgi.com
Subject: Re: 2.4.0-test7: Trouble with ipchains (2.2-style) support 
In-reply-to: Your message of "Wed, 06 Sep 2000 01:58:59 EDT."
             <39B5DD23.8C5D46DC@webdata.dyndns.org> 
Date:   Fri, 08 Sep 2000 12:33:14 +1100
Message-Id: <20000908013314.8BE92813C@halfway.linuxcare.com.au>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In message <39B5DD23.8C5D46DC@webdata.dyndns.org> you write:
> I'm having trouble with linux kernel 2.4.0-test7 reguarding the
> Networking
> Options / IP: Netfilter Configuration / ipchains (2.2-style) support.
> Here is
> what I am experiencing:

> 1) When using a linux client behind the firewall, I can browse to
> www1.sympatico.ca using lynx no problem. However, when I use Netscape it
> says
> it's Transferring data from the site but nothing happens. It just sits
> there.

Looks like classic ICMP DF problem.  The MTU of your PPPoE link is <
1500, and these machines are filtering out ICMPs, so they don't get
back to them (from the ISP's PPPoE end).

This is not a problem with Linux at all, but to prove it (we've had
ICMP translation problems in the past in the 2.4 series), you can do a
tcpdump from a client (tcpdump -s1514 -x -n -p), then try to access
one of these `bad' sites with netscape.

You should see a successful TCP handshake, then netscape trying to
send a big (1500-byte) packet, then the firewall sending an `ICMP
unreachable: Fragmentation Needed', then netscape sending a smaller
packet, which gets through (you'll see an ACK)...

If this is the case, there are several solutions:

1) Complain loudly to the sites which are blocking ICMP unreachable
   errors.  They are shooting themselves in the foot.

2) Reduce the MTU of every ethernet interface inside your network to
   that of the PPPoE link.

3) Use the CVS version of iptables, and do `make patch-o-matic': apply
   the TCPMSS patch, recompile the kernel, then use that to mangle the
   MSS of outgoing TCP packets.

Sorry,
Rusty.
--
Hacking time.

From owner-netdev@oss.sgi.com Sun Sep 10 17:05:29 2000
Received:  by oss.sgi.com id <S42204AbQIKAFJ>;
	Sun, 10 Sep 2000 17:05:09 -0700
Received: from natmail2.webmailer.de ([192.67.198.65]:14071 "EHLO
        post.webmailer.de") by oss.sgi.com with ESMTP id <S42199AbQIKAEn>;
	Sun, 10 Sep 2000 17:04:43 -0700
Received: from frog.athome (pec-90-152.tnt4.s2.uunet.de [149.225.90.152])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id CAA22918;
	Mon, 11 Sep 2000 02:03:03 +0200 (MET DST)
Received: from localhost (hgfelger@localhost)
	by frog.athome (8.9.3/8.9.3) with ESMTP id BAA01427;
	Mon, 11 Sep 2000 01:56:35 +0200
X-Authentication-Warning: frog.athome: hgfelger owned process doing -bs
Date:   Mon, 11 Sep 2000 01:56:28 +0200 (CEST)
From:   Hartwig Felger <hgfelger@hgfelger.de>
X-Sender: hgfelger@frog.athome
Reply-To: hgfelger@hgfelger.de
To:     Marc Boucher <marc@mbsi.ca>
cc:     jamal <hadi@cyberus.ca>, netdev@oss.sgi.com,
        mostrows@styx.uwaterloo.ca, rusty@linuxcare.com.au,
        netfilter-devel@us4.samba.org
Subject: Re: dsl masquerading over linux 2.4.0-test[78]pre... 
In-Reply-To: <200009071906.e87J64g07611@opium.mbsi.ca>
Message-ID: <Pine.LNX.4.10.10009110153230.1191-100000@frog.athome>
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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salut Marc,
thanX a lot. Your soloution seems to work for me!!!! Ok, I did not test it
very extensiv... I hope, that it is ok for you, that I published this
soloution on my web-page: www.hgfelger.de/mss/mss.html

On Thu, 7 Sep 2000, Marc Boucher wrote:
> Earlier I wrote:
> > 
> > As Jamal says, mssclampfw can do the trick but since you are already
> > using iptables installed I would recommend its TCPMSS match&target
> > modules instead. These are in the tcp-MSS patch which can be found under
> > netfilter/userspace/patch-o-matic/ (in the CVS repository, or next
> > upcoming iptables release > 1.1.1). Use the ./runme script in that same
> > directory to apply it, then recompile iptables and reconfigure/rebuild
> > your kernel with CONFIG_IP_NF_MATCH_TCPMSS and
> > CONFIG_IP_NF_TARGET_TCPMSS enabled.
> > 
> > Then you need a rule like:
> > 
> > iptables -t nat -A POSTROUTING -o pppoe_interface \
> >     -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss mtuofpppoeintf-40+1: \
> >     -j TCPMSS --set-mss mtuofpppoeintf-40
> > 
> > so for example if the outgoing PPPoE interface is ppp0 with an mtu of 
> > 1492, you would have:
> > 
> > iptables -t nat -A POSTROUTING -o ppp0 \
> >     -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1453: \
> >     -j TCPMSS --set-mss 1452
> > 
> > Replacing "-t nat -A POSTROUTING" with "-A FORWARD" should also work.
> 
> Actually it will work better with "-A FORWARD", since the nat table
> apparently doesn't "see" SYN ACK packets, whose MSS also needs to be
> adjusted in the case of incoming connections relayed to hosts behind the
> firewall with DNAT..
> 
> Marc

- -- 
1024D/339FD693 Hartwig Felger <hgfelger@hgfelger.de>
Key fingerprint = FB2F 3EE9 345A D55B 6FF2  0EC1 F5B0 684F 339F D693
For the pulic keys, please visit my page.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5vB+z9bBoTzOf1pMRAhgeAJwIIiW27gFaY6s1r0BfjcpD7zzWbwCgnKr6
8loDugHm7F7s/+k7uLC08ZI=
=nMdS
-----END PGP SIGNATURE-----


From owner-netdev@oss.sgi.com Sun Sep 10 22:56:44 2000
Received:  by oss.sgi.com id <S42229AbQIKF4e>;
	Sun, 10 Sep 2000 22:56:34 -0700
Received: from linuxcare.com.au ([203.29.91.49]:12041 "EHLO
        front.linuxcare.com.au") by oss.sgi.com with ESMTP
	id <S42199AbQIKF4S>; Sun, 10 Sep 2000 22:56:18 -0700
Received: from halfway.linuxcare.com.au (localhost [127.0.0.1])
	by front.linuxcare.com.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA03009
	for <netdev@oss.sgi.com>; Mon, 11 Sep 2000 16:55:58 +1100
X-Authentication-Warning: front.linuxcare.com.au: Host localhost [127.0.0.1] claimed to be halfway.linuxcare.com.au
Received: from linuxcare.com.au (localhost [127.0.0.1])
	by halfway.linuxcare.com.au (Postfix) with ESMTP
	id 7FBAC813D; Mon, 11 Sep 2000 15:55:00 +1100 (EST)
From:   Rusty Russell <rusty@linuxcare.com.au>
To:     Marc Boucher <marc@mbsi.ca>
Cc:     netfilter-devel@us4.samba.org, netdev@oss.sgi.com
Subject: Re: dsl masquerading over linux 2.4.0-test[78]pre... 
In-reply-to: Your message of "Thu, 07 Sep 2000 14:14:40 EDT."
             <200009071814.e87IEfA06978@opium.mbsi.ca> 
Date:   Mon, 11 Sep 2000 15:55:00 +1100
Message-Id: <20000911045500.7FBAC813D@halfway.linuxcare.com.au>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In message <200009071814.e87IEfA06978@opium.mbsi.ca> you write:
> Rusty, what would you think of adding the missing hooks to the 'mangle'
> table; extending its purpose to general packet alteration, not just
> changing stuff that influences routing?

Yes; this would be a win.  Since it's generally a network hackers toy,
we should make it less restrictive.  But the code freeze means it will
remain a separate patch until 2.4.1 at least.

Now: what priority should it be?  Does it matter?

> I am also considering implementing a --clamp-mss-to-mtu option to the

This would be excellent; even better to use the path mtu, so if
someone else has a lower MTU (causing the first TCP connection to
stall), the second one might succeed.

Rusty.
--
Hacking time.

From owner-netdev@oss.sgi.com Mon Sep 11 07:13:10 2000
Received:  by oss.sgi.com id <S42243AbQIKONA>;
	Mon, 11 Sep 2000 07:13:00 -0700
Received: from mail.inconnect.com ([209.140.64.7]:7562 "HELO
        mail.inconnect.com") by oss.sgi.com with SMTP id <S42241AbQIKOMa>;
	Mon, 11 Sep 2000 07:12:30 -0700
Received: (qmail 11567 invoked from network); 11 Sep 2000 14:12:30 -0000
Received: from ultra1.inconnect.com (209.140.64.2)
  by mail with SMTP; 11 Sep 2000 14:12:30 -0000
Date:   Mon, 11 Sep 2000 08:12:29 -0600 (MDT)
From:   Keyshaun <thekernel@subdimension.com>
X-Sender: kruger@ultra1.inconnect.com
To:     Linux Netdev <netdev@oss.sgi.com>
Subject: iptables
Message-ID: <Pine.SOL.4.21.0009110807170.15821-100000@ultra1.inconnect.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

Last time I was looking at 2.4 I don't recall seeing anything about
iptables.  I am kind of wondering what it is.  I havn't looked at it
myself because caldera won't work well enough for me to setup my dev
system as I want to.  Even now I am using telnet on windows to get my
mail.  *shudder* Anyway, a link to information as to what iptables is/does
would be appreciated.

Shaun Kruger

BTW: are there any good books about writing network device drivers?


From owner-netdev@oss.sgi.com Mon Sep 11 14:48:01 2000
Received:  by oss.sgi.com id <S42258AbQIKVrv>;
	Mon, 11 Sep 2000 14:47:51 -0700
Received: from gw.simegen.com ([203.2.135.4]:58379 "EHLO keon.simegen.com")
	by oss.sgi.com with ESMTP id <S42241AbQIKVrd>;
	Mon, 11 Sep 2000 14:47:33 -0700
Received: from co3019724-a.thoms1.vic.optushome.com.au (anaconda.simegen.com) [203.164.36.115] 
	by keon.simegen.com with esmtp (Exim 3.12 #1 (Debian))
	id 13YbPw-0008RF-00; Tue, 12 Sep 2000 08:47:09 +1100
Received: from localhost
	([127.0.0.1] helo=zeor.simegen.com ident=dancer)
	by anaconda.simegen.com with esmtp (Exim 3.16 #1 (Debian))
	id 13YbPS-0000EM-00; Tue, 12 Sep 2000 08:46:38 +1100
Message-ID: <39BD52BE.134D90B9@zeor.simegen.com>
Date:   Tue, 12 Sep 2000 08:46:38 +1100
From:   dancer@zeor.simegen.com
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Keyshaun <thekernel@subdimension.com>
CC:     Linux Netdev <netdev@oss.sgi.com>
Subject: Re: iptables
References: <Pine.SOL.4.21.0009110807170.15821-100000@ultra1.inconnect.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

Keyshaun wrote:

> Last time I was looking at 2.4 I don't recall seeing anything about
> iptables.  I am kind of wondering what it is.  I havn't looked at it
> myself because caldera won't work well enough for me to setup my dev
> system as I want to.  Even now I am using telnet on windows to get my
> mail.  *shudder* Anyway, a link to information as to what iptables is/does
> would be appreciated.
>
> Shaun Kruger
>
> BTW: are there any good books about writing network device drivers?

iptables is in there, definitely....and it rocks.

If it's up, you can try Rusty's unreliable guides:
http://netfilter.kernelnotes.org/unreliable-guides/

D


From owner-netdev@oss.sgi.com Mon Sep 11 20:30:14 2000
Received:  by oss.sgi.com id <S42267AbQILD3y>;
	Mon, 11 Sep 2000 20:29:54 -0700
Received: from HSE-MTL-ppp66885.qc.sympatico.ca ([64.229.179.28]:15496 "EHLO
        opium.mbsi.ca") by oss.sgi.com with ESMTP id <S42264AbQILD3d>;
	Mon, 11 Sep 2000 20:29:33 -0700
Received: from opium.mbsi.ca (marc@localhost [127.0.0.1])
	by opium.mbsi.ca (8.11.0/8.11.0) with ESMTP id e8C3RVg06232;
	Mon, 11 Sep 2000 23:27:31 -0400 (EDT)
Message-Id: <200009120327.e8C3RVg06232@opium.mbsi.ca>
X-Mailer: exmh version 2.2 07/04/2000 with nmh-1.0.4+dev
To:     Rusty Russell <rusty@linuxcare.com.au>
cc:     netfilter-devel@us4.samba.org, netdev@oss.sgi.com,
        hgfelger@hgfelger.de
Subject: Re: dsl masquerading over linux 2.4.0-test[78]pre... 
In-Reply-To: Your message of "Mon, 11 Sep 2000 15:55:00 +1100."
             <20000911045500.7FBAC813D@halfway.linuxcare.com.au> 
References: <20000911045500.7FBAC813D@halfway.linuxcare.com.au> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Mon, 11 Sep 2000 23:27:31 -0400
From:   Marc Boucher <marc@mbsi.ca>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Hi Rusty,

> In message <200009071814.e87IEfA06978@opium.mbsi.ca> you write:
> > Rusty, what would you think of adding the missing hooks to the 'mangle'
> > table; extending its purpose to general packet alteration, not just
> > changing stuff that influences routing?
> 
> Yes; this would be a win.  Since it's generally a network hackers toy,
> we should make it less restrictive.  But the code freeze means it will
> remain a separate patch until 2.4.1 at least.

IMHO such a straightforward/low-risk change should go in right away.

Why not look at it as a "design bug-fix" rather than a feature addition?
:-)

> Now: what priority should it be?  Does it matter?

You mean hook priority? I don't think it really matters in this case.

> > I am also considering implementing a --clamp-mss-to-mtu option to the
> 
> This would be excellent; even better to use the path mtu, so if
> someone else has a lower MTU (causing the first TCP connection to
> stall), the second one might succeed.

Ok, support for --clamp-mss-to-pmtu option has been implemented and
checked-in; please review code changes.

Recommended usage is now:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

[but wouldn't it be neater with "-t mangle" ? :-)] 

Cheers,
Marc

> Rusty.
> --
> Hacking time.
> 



From owner-netdev@oss.sgi.com Tue Sep 12 06:32:11 2000
Received:  by oss.sgi.com id <S42274AbQILNcB>;
	Tue, 12 Sep 2000 06:32:01 -0700
Received: from csa.iisc.ernet.in ([144.16.67.8]:39434 "EHLO csa.iisc.ernet.in")
	by oss.sgi.com with ESMTP id <S42243AbQILNbu>;
	Tue, 12 Sep 2000 06:31:50 -0700
Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46])
	by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id TAA23846
	for <netdev@oss.sgi.com>; Tue, 12 Sep 2000 19:00:34 +0530
Received: from localhost (prasanna@localhost)
	by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id TAA22677
	for <netdev@oss.sgi.com>; Tue, 12 Sep 2000 19:01:18 +0530
X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs
Date:   Tue, 12 Sep 2000 19:01:18 +0530 (IST)
From:   Gaitonde Anandprasanna <prasanna@csa.iisc.ernet.in>
Reply-To: Gaitonde Anandprasanna <prasanna@csa.iisc.ernet.in>
To:     netdev@oss.sgi.com
Subject: Query from a Student 
Message-ID: <Pine.LNX.3.96.1000912185949.22632F-100000@helios.csa.iisc.ernet.in>
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



Respected Sir,

   I am a student of Indian Institute of Science from the department of 
Computer Science and Autmation and i am doing my final
year project. 
   My project involves the implementation of extensions to RSVP protocol
for traffic Engineering.
  But before that i am teting the exisitng software of RSVP. and at
present want to use it for reserving resources like bandwidth for a
particular session.

I came acrross u'r code wherein u have developed the actual treaffic
control interface to the Kerenel. But is it that before using RSVP over
the traffic control. I need to configure Traffic Control inside the
Kernel?

   I then used your TC utility which helps us in doing this configuring of
Traffic Control. (that is creation of Queueing discplines and classes and
filters). 

I would be very much grateful to u if u can advise me as to what kind of
 Queueing discplines and classes need to be configured over the interface
so as to use RSVP over it.

I have tried ussing the cbqinit.eth0 in the TC package and then starting
rsvpd but it doesnt seem to make any reservations. Can u tell me what can
be the problem . Do i have to change anything in the the cbqinit.eth0
script. or can u direct me to some other initailsation script.


Please advise me so that i can use RSVP to make actual reservations.
(for eg. say i want to reserve some bandwidth for ftp session between two
machines then what do i do?)

I will be most grateful to u  if u can help me on this issue.


I am sorry for taking much of u'r time.

Thanking in advance

Yours sincerely

Prasanna


                 
                     _____________________________                  
                   _ |ANANDPRASANNA GAITONDE     | _ 
                  / )|COMP. SCIENCE & AUTOMATION |( \
                 / / |D-7,IISc HOSTEL            | \ \
                / /  |INDIAN INSTITUTE OF SCIENCE|  \ \
              _( (_  |BANGALORE-560012.          |  _) )_
              (((\ \>|_/->___________________<-\_|</ /)))
              (\\\\ \_/ /LAB Ph.(080)3092906  \ \_/ ////)
               \       /HOSTEL Ph.-            \       /  
                \    _/     (080)3092452        \_    /     
                /   /-----------------------------\   \                  
               /  Email Id-                            \ 
              /      prasanna@csa.iisc.ernet.in         \
	     ---------------------------------------------
            -----------------------------------------------

--------------------------------------------------------------------------------
		
*************************************************************************  
| | | | __ ___   _____     __ _    _ __ (_) ___ ___     __| | __ _ _   _
| |_| |/ _` \ \ / / _ \   / _` |  | '_ \| |/ __/ _ \   / _` |/ _` | | | |
|  _  | (_| |\ V /  __/  | (_| |  | | | | | (_|  __/  | (_| | (_| | |_| |
|_| |_|\__,_| \_/ \___|   \__,_|  |_| |_|_|\___\___|   \__,_|\__,_|\__, |
*************************************************************************









From owner-netdev@oss.sgi.com Tue Sep 12 15:05:03 2000
Received:  by oss.sgi.com id <S42244AbQILWEy>;
	Tue, 12 Sep 2000 15:04:54 -0700
Received: from lsi.lsil.com ([147.145.40.2]:55990 "EHLO lsi.lsil.com")
	by oss.sgi.com with ESMTP id <S42209AbQILWEo>;
	Tue, 12 Sep 2000 15:04:44 -0700
Received: from mhbs.lsil.com ([147.145.31.100])
	by lsi.lsil.com (8.9.3+Sun/8.9.1) with ESMTP id PAA00306
	for <netdev@oss.sgi.com>; Tue, 12 Sep 2000 15:04:43 -0700 (PDT)
Received: from inca.co.lsil.com by mhbs.lsil.com with ESMTP for netdev@oss.sgi.com; Tue, 12 Sep 2000 15:04:34 -0700
Received: from ra.ks.lsil.com (ra.ks.lsil.com [153.79.162.3])
	by inca.co.lsil.com (8.9.3/8.9.3) with SMTP id QAA09229;
	Tue, 12 Sep 2000 16:04:27 -0600 (MDT)
Received: from lsil.com by ra.ks.lsil.com (SMI-8.6/SMI-SVR4)
	id RAA05422; Tue, 12 Sep 2000 17:04:27 -0500
Message-Id: <39BEA845.229F9494@lsil.com>
Date:   Tue, 12 Sep 2000 17:03:49 -0500
From:   Noah Romer <nromer@lsil.com>
Reply-To: noah.romer@lsil.com
Organization: LSI Logic
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev@oss.sgi.com, "Romer, Noah" <noah.romer@lsil.com>
Subject: 2.4.0-testx: who calls ip_rcv (in ipv4/ip_input.c)?
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'm trying to trace the path of packets through the networking layers after
they're handed off from the driver via netif_rx. I see where they're placed in
the input_pkt_queue in netif_rx, and taken off of the queue in net_rx_action (I
thought I'd traced them to functions in p8022.c and psnap.c, but it doesn't
appear that either of those files get compiled on my system, so I guess not).
Then I found where the packets get handled in ip_rcv and then ip_rcv_finish,
but I haven't been able to figure out who calls ip_rcv.

Thanks.

From owner-netdev@oss.sgi.com Wed Sep 13 15:09:03 2000
Received:  by oss.sgi.com id <S42315AbQIMWIm>;
	Wed, 13 Sep 2000 15:08:42 -0700
Received: from kogge.hanse.de ([192.76.134.17]:7175 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S42279AbQIMWIb>;
	Wed, 13 Sep 2000 15:08:31 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id AAA55422;
	Thu, 14 Sep 2000 00:12:56 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id VAA05810;
	Wed, 13 Sep 2000 21:35:45 +0200
To:     noah.romer@lsil.com
cc:     netdev@oss.sgi.com
Subject: Re: 2.4.0-testx: who calls ip_rcv (in ipv4/ip_input.c)?
References: <39BEA845.229F9494@lsil.com>
From:   Henner Eisen <eis@baty.hanse.de>
Date:   13 Sep 2000 21:35:45 +0200
In-Reply-To: Noah Romer's message of "Tue, 12 Sep 2000 17:03:49 -0500"
Message-ID: <ouvgw0f5ke.fsf@baty.hanse.de>
Lines:  18
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


Hi,

>>>>> "Noah" == Noah Romer <nromer@lsil.com> writes:

    Noah> Then I found where the packets get handled in ip_rcv and
    Noah> then ip_rcv_finish, but I haven't been able to figure out
    Noah> who calls ip_rcv.

Protocols register their receive methods by means of dev_add_pack().
That should be your starting point. They are called via the func() function
pointer member of struct packet_type. Try

	 grep \>.\*func /usr/src/linux/net/core/dev.c

for possible locations.

Henner

From owner-netdev@oss.sgi.com Thu Sep 14 00:39:48 2000
Received:  by oss.sgi.com id <S42317AbQINHji>;
	Thu, 14 Sep 2000 00:39:38 -0700
Received: from nbgdi6-212-144-224-021.arcor-ip.net ([212.144.224.21]:27640
        "EHLO coruscant.gnumonks.org") by oss.sgi.com with ESMTP
	id <S42313AbQINHjR>; Thu, 14 Sep 2000 00:39:17 -0700
Received: from laforge by coruscant.gnumonks.org with local (Exim 3.16 #1)
	id 13ZTcL-0005l9-00; Thu, 14 Sep 2000 09:39:33 +0200
Date:   Thu, 14 Sep 2000 09:39:33 +0200
From:   Harald Welte <laforge@gnumonks.org>
To:     Noah Romer <nromer@lsil.com>
Cc:     netdev@oss.sgi.com
Subject: Re: 2.4.0-testx: who calls ip_rcv (in ipv4/ip_input.c)?
Message-ID: <20000914093933.Z9480@coruscant.gnumonks.org>
References: <39BEA845.229F9494@lsil.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <39BEA845.229F9494@lsil.com>; from nromer@lsil.com on Tue, Sep 12, 2000 at 05:03:49PM -0500
X-Operating-System: Linux coruscant.gnumonks.org 2.2.16-3
X-Date: Today is Sweetmorn, the 32nd day of Bureaucracy in the YOLD 3166
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, Sep 12, 2000 at 05:03:49PM -0500, Noah Romer wrote:

> I'm trying to trace the path of packets through the networking layers after
> they're handed off from the driver via netif_rx. I see where they're placed in
> the input_pkt_queue in netif_rx, and taken off of the queue in net_rx_action (I

Just have a look at http://www.sunbeam.franken.de/projects/packetjourney
this document describes the path of a received network packet through the 
whole network stack including all functions and what they do.

> Thanks.

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org                http://www.gnumonks.org
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

From owner-netdev@oss.sgi.com Thu Sep 14 01:45:48 2000
Received:  by oss.sgi.com id <S42353AbQINIp2>;
	Thu, 14 Sep 2000 01:45:28 -0700
Received: from panic.ohr.gatech.edu ([130.207.47.194]:64261 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S42339AbQINIpI>;
	Thu, 14 Sep 2000 01:45:08 -0700
Received: from mandrakesoft.com (adsl-77-228-135.atl.bellsouth.net [216.77.228.135])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id EAA03171;
	Thu, 14 Sep 2000 04:44:55 -0400
Message-ID: <39C09005.E3A873B3@mandrakesoft.com>
Date:   Thu, 14 Sep 2000 04:44:53 -0400
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0-test8 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
CC:     netdev@oss.sgi.com
Subject: Preallocated skb's?
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

Does anyone think that allocating skbs during system idle time would be
useful?

Net drivers (well, ethernet at least) often wind up allocating
maximum-sized skb's for use in Rx descriptors.  It seems to me that it
would be useful at interrupt time to have an skb already allocated,
falling back on current dev_alloc_skb behavior during times of system
load.

	Jeff



-- 
Jeff Garzik              | Windows NT Performance,
Building 1024            | on the next "In Search Of"
MandrakeSoft, Inc.       |

From owner-netdev@oss.sgi.com Thu Sep 14 01:49:18 2000
Received:  by oss.sgi.com id <S42356AbQINIs6>;
	Thu, 14 Sep 2000 01:48:58 -0700
Received: from pizda.ninka.net ([216.101.162.242]:56208 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42339AbQINIs4>;
	Thu, 14 Sep 2000 01:48:56 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id BAA22073;
	Thu, 14 Sep 2000 01:36:24 -0700
Date:   Thu, 14 Sep 2000 01:36:24 -0700
Message-Id: <200009140836.BAA22073@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     jgarzik@mandrakesoft.com
CC:     linux-kernel@vger.kernel.org, netdev@oss.sgi.com
In-reply-to: <39C09005.E3A873B3@mandrakesoft.com> (message from Jeff Garzik on
	Thu, 14 Sep 2000 04:44:53 -0400)
Subject: Re: Preallocated skb's?
References:  <39C09005.E3A873B3@mandrakesoft.com>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date: 	Thu, 14 Sep 2000 04:44:53 -0400
   From: Jeff Garzik <jgarzik@mandrakesoft.com>

   Does anyone think that allocating skbs during system idle time
   would be useful?

I really don't like these sorts of things, because it makes an
assumption as to what memory is about to be used for.

What if you were to preallocate skbs while idle, then the next thing
which happens is some userland program walks over a 2gb dataset and
no network activity happens at all.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Thu Sep 14 03:54:09 2000
Received:  by oss.sgi.com id <S42188AbQINKx6>;
	Thu, 14 Sep 2000 03:53:58 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:51397 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42186AbQINKxj>;
	Thu, 14 Sep 2000 03:53:39 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id GAA09563;
	Thu, 14 Sep 2000 06:53:38 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id GAA13964;
	Thu, 14 Sep 2000 06:53:37 -0400 (EDT)
Date:   Thu, 14 Sep 2000 06:53:37 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     "David S. Miller" <davem@redhat.com>
cc:     jgarzik@mandrakesoft.com, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: Preallocated skb's?
In-Reply-To: <200009140836.BAA22073@pizda.ninka.net>
Message-ID: <Pine.GSO.4.20.0009140633290.5288-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 Thu, 14 Sep 2000, David S. Miller wrote:

>    Date: 	Thu, 14 Sep 2000 04:44:53 -0400
>    From: Jeff Garzik <jgarzik@mandrakesoft.com>
> 
>    Does anyone think that allocating skbs during system idle time
>    would be useful?
> 
> I really don't like these sorts of things, because it makes an
> assumption as to what memory is about to be used for.
> 
> What if you were to preallocate skbs while idle, then the next thing
> which happens is some userland program walks over a 2gb dataset and
> no network activity happens at all.
> 

The FF code of the tulip does have skb recycling code.
And i belive Jes' acenic code does or did at some point. 
Robert Olson and I were thinking of taking out that code out of the
tulip for reasons such as you talk about (and the thought maybe that
the per-CPU slab might have obsoleted that requirement). We did some tests
with 2.4.0-test7 and were suprised to observe that at high rate of input
packets, it still made as a big a difference as 7000 packets per second
;-> i.e we got 7Kpps more by using skb recycling.

Dave, would a scheme with an aging of the skbs in the recycle queue
and an upper bound of the number of packets sitting on the queue be
acceptable?
Maybe ANK can make a comment as well.
Robert and I plan to play with such a scheme for a long time under many 
different scenarios and come with numbers (throughput etc) instead of
"here's a patch and intuitively it makes sense". 
This is really a 2.5 thing if acceptable.

cheers,
jamal

PS:- OLS patch coming soon; a few more tests (as time permits);-> 


From owner-netdev@oss.sgi.com Thu Sep 14 05:07:59 2000
Received:  by oss.sgi.com id <S42190AbQINMHj>;
	Thu, 14 Sep 2000 05:07:39 -0700
Received: from sphinx.mythic-beasts.com ([195.82.107.246]:33801 "EHLO
        sphinx.mythic-beasts.com") by oss.sgi.com with ESMTP
	id <S42186AbQINMHV>; Thu, 14 Sep 2000 05:07:21 -0700
Received: from matthew (helo=localhost)
	by sphinx.mythic-beasts.com with local-esmtp (Exim 3.13 #8)
	id 13ZXmF-0004OE-00; Thu, 14 Sep 2000 13:06:03 +0100
Date:   Thu, 14 Sep 2000 13:06:03 +0100 (BST)
From:   Matthew Kirkwood <matthew@hairy.beasts.org>
X-Sender: matthew@sphinx.mythic-beasts.com
To:     "David S. Miller" <davem@redhat.com>
cc:     jgarzik@mandrakesoft.com, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: Preallocated skb's?
In-Reply-To: <200009140836.BAA22073@pizda.ninka.net>
Message-ID: <Pine.LNX.4.10.10009141305210.15291-100000@sphinx.mythic-beasts.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 Thu, 14 Sep 2000, David S. Miller wrote:

>    Does anyone think that allocating skbs during system idle time
>    would be useful?
> 
> I really don't like these sorts of things, because it makes an
> assumption as to what memory is about to be used for.

I agree.  Surely The Linux Way (tm) would be to make the
allocations so cheap that prealocation would gain you
nothing.

Matthew.


From owner-netdev@oss.sgi.com Thu Sep 14 05:08:19 2000
Received:  by oss.sgi.com id <S42210AbQINMH7>;
	Thu, 14 Sep 2000 05:07:59 -0700
Received: from pizda.ninka.net ([216.101.162.242]:46738 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42186AbQINMHy>;
	Thu, 14 Sep 2000 05:07:54 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id EAA24482;
	Thu, 14 Sep 2000 04:55:16 -0700
Date:   Thu, 14 Sep 2000 04:55:16 -0700
Message-Id: <200009141155.EAA24482@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     hadi@cyberus.ca
CC:     jgarzik@mandrakesoft.com, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
In-reply-to: <Pine.GSO.4.20.0009140633290.5288-100000@shell.cyberus.ca>
	(message from jamal on Thu, 14 Sep 2000 06:53:37 -0400 (EDT))
Subject: Re: Preallocated skb's?
References:  <Pine.GSO.4.20.0009140633290.5288-100000@shell.cyberus.ca>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date: Thu, 14 Sep 2000 06:53:37 -0400 (EDT)
   From: jamal <hadi@cyberus.ca>

   Dave, would a scheme with an aging of the skbs in the recycle queue
   and an upper bound of the number of packets sitting on the queue be
   acceptable?

This sounds more reasonable, certainly.  Perhaps you and Jeff should
collaborate :-)

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Thu Sep 14 05:16:19 2000
Received:  by oss.sgi.com id <S42212AbQINMP6>;
	Thu, 14 Sep 2000 05:15:58 -0700
Received: from Cantor.suse.de ([194.112.123.193]:61444 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42186AbQINMPx>;
	Thu, 14 Sep 2000 05:15:53 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id CBC4A1E2EC; Thu, 14 Sep 2000 14:15:34 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 31F8810A02F; Thu, 14 Sep 2000 14:15:34 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 7F2312F300; Thu, 14 Sep 2000 14:15:27 +0200 (MEST)
Date:   Thu, 14 Sep 2000 14:15:27 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     "David S. Miller" <davem@redhat.com>
Cc:     hadi@cyberus.ca, jgarzik@mandrakesoft.com,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: Preallocated skb's?
Message-ID: <20000914141527.A6891@gruyere.muc.suse.de>
References: <Pine.GSO.4.20.0009140633290.5288-100000@shell.cyberus.ca> <200009141155.EAA24482@pizda.ninka.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200009141155.EAA24482@pizda.ninka.net>; from davem@redhat.com on Thu, Sep 14, 2000 at 04:55:16AM -0700
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Thu, Sep 14, 2000 at 04:55:16AM -0700, David S. Miller wrote:
>    Date: Thu, 14 Sep 2000 06:53:37 -0400 (EDT)
>    From: jamal <hadi@cyberus.ca>
> 
>    Dave, would a scheme with an aging of the skbs in the recycle queue
>    and an upper bound of the number of packets sitting on the queue be
>    acceptable?
> 
> This sounds more reasonable, certainly.  Perhaps you and Jeff should
> collaborate :-)

Instead of explicit aging you could just use the skb_head slab cache for that:
just kmalloc/kfree the data area in the slab constructor/destructor. This
could probably give you most of the advantages of recycled skbs (less
header setups) etc. in the slab environment.  You may need to tune the
slab cache prunning algorithms for that a bit though because the weight
of a skbhead would be much more heavy (e.g. by giving the skbhead slab cache a
bigger priority for prunning) 


-Andi



From owner-netdev@oss.sgi.com Thu Sep 14 05:17:49 2000
Received:  by oss.sgi.com id <S42236AbQINMRi>;
	Thu, 14 Sep 2000 05:17:38 -0700
Received: from smtp1.cern.ch ([137.138.128.38]:49668 "EHLO smtp1.cern.ch")
	by oss.sgi.com with ESMTP id <S42186AbQINMRe>;
	Thu, 14 Sep 2000 05:17:34 -0700
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 OAA12204;
	Thu, 14 Sep 2000 14:17:14 +0200 (MET DST)
Received: (from jes@localhost)
	by lxplus015.cern.ch (8.9.3/8.9.3) id OAA16608;
	Thu, 14 Sep 2000 14:17:13 +0200
To:     jamal <hadi@cyberus.ca>
Cc:     "David S. Miller" <davem@redhat.com>, jgarzik@mandrakesoft.com,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: Preallocated skb's?
References: <Pine.GSO.4.20.0009140633290.5288-100000@shell.cyberus.ca>
From:   Jes Sorensen <jes@linuxcare.com>
Date:   14 Sep 2000 14:17:13 +0200
In-Reply-To: jamal's message of "Thu, 14 Sep 2000 06:53:37 -0400 (EDT)"
Message-ID: <d33dj3goc6.fsf@lxplus015.cern.ch>
Lines:  17
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

>>>>> "jamal" == jamal  <hadi@cyberus.ca> writes:

jamal> The FF code of the tulip does have skb recycling code.  And i
jamal> belive Jes' acenic code does or did at some point.  Robert
jamal> Olson and I were thinking of taking out that code out of the
jamal> tulip for reasons such as you talk about (and the thought maybe
jamal> that the per-CPU slab might have obsoleted that
jamal> requirement). We did some tests with 2.4.0-test7 and were
jamal> suprised to observe that at high rate of input packets, it
jamal> still made as a big a difference as 7000 packets per second ;->
jamal> i.e we got 7Kpps more by using skb recycling.

I tried recycling in the acenic driver, but after adding Ingo's early
per CPU slab caches I couldn't see any measurable performance gain
from using recycling.

Jes

From owner-netdev@oss.sgi.com Thu Sep 14 06:00:19 2000
Received:  by oss.sgi.com id <S42245AbQINNAJ>;
	Thu, 14 Sep 2000 06:00:09 -0700
Received: from horus.its.uow.edu.au ([130.130.68.25]:58254 "EHLO
        horus.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42186AbQINM7v>;
	Thu, 14 Sep 2000 05:59:51 -0700
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 XAA09914;
	Thu, 14 Sep 2000 23:59:21 +1100 (EST)
Message-ID: <39C0CBB4.D75577A3@uow.edu.au>
Date:   Thu, 14 Sep 2000 23:59:32 +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:     jamal <hadi@cyberus.ca>
CC:     "David S. Miller" <davem@redhat.com>, jgarzik@mandrakesoft.com,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: Preallocated skb's?
References: <200009140836.BAA22073@pizda.ninka.net> <Pine.GSO.4.20.0009140633290.5288-100000@shell.cyberus.ca>
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

jamal wrote:
> 
> The FF code of the tulip does have skb recycling code.
> And i belive Jes' acenic code does or did at some point.

But this isn't preallocation.  Unless you got cute, this scheme would
limit the "preallocation" to the DMA ring size.

For network-intensive applications, a larger pool of preallocated
buffers would allow a driver to handle Rx packet bursts more
gracefully.   Make the pool size tunable to match the desired max burst
size, as well as to avoid davem's Oracle problem.

At present we perform the allocation at interrupt time which is
precisely when we shouldn't.  A background kernel thread which keeps the
pool topped up would even things out and would give a significant
increase in our peak Rx rates, up to a particular burst size.

This is considerable smarter than simply tweaking the driver for huge
DMA ring sizes.  It is pretty specialised though.

One big bonus: the packets can then be allocated GFP_KERNEL rather than
GFP_ATOMIC.

Oh.

A quick measurement says dev_alloc_skb(1000) takes about 450 cycles
on x86.  At 150 kpps that's a potential 10% loss from your peak
burst rate.

But for 3c59x (which is not a very efficient driver (yet)), it takes 6
usecs to even get into the ISR, and around 4 uSecs to traverse it. 
Guess another 4 to leave the ISR, guess half as much again for whoever
got interrupted to undo the resulting cache pollution.

That's 20 usec per interrupt, of which 1 usec could be saved by skb
pooling.


If you don't do Rx interrupt mitigation there's no point in event
thinking about skb pooling.

From owner-netdev@oss.sgi.com Thu Sep 14 06:55:08 2000
Received:  by oss.sgi.com id <S42248AbQINNyt>;
	Thu, 14 Sep 2000 06:54:49 -0700
Received: from Cantor.suse.de ([194.112.123.193]:45325 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42186AbQINNyb>;
	Thu, 14 Sep 2000 06:54:31 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id BC0CA1E429; Thu, 14 Sep 2000 15:54:29 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 167D210A02A; Thu, 14 Sep 2000 15:54:29 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id B17442F300; Thu, 14 Sep 2000 15:54:27 +0200 (MEST)
Date:   Thu, 14 Sep 2000 15:54:27 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Andrew Morton <andrewm@uow.edu.au>
Cc:     jamal <hadi@cyberus.ca>, "David S. Miller" <davem@redhat.com>,
        jgarzik@mandrakesoft.com, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: Preallocated skb's?
Message-ID: <20000914155427.A9314@gruyere.muc.suse.de>
References: <200009140836.BAA22073@pizda.ninka.net> <Pine.GSO.4.20.0009140633290.5288-100000@shell.cyberus.ca> <39C0CBB4.D75577A3@uow.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <39C0CBB4.D75577A3@uow.edu.au>; from andrewm@uow.edu.au on Thu, Sep 14, 2000 at 11:59:32PM +1100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Thu, Sep 14, 2000 at 11:59:32PM +1100, Andrew Morton wrote:
> That's 20 usec per interrupt, of which 1 usec could be saved by skb
> pooling.

FF usually runs with interrupt mitigation at higher rates (8-16 or even
more packets / interrupt). I agree though that it probably does not 
make too much difference.  alloc_skb could probably be made cheaper 
for the FF case by being more clever in the slab constructor (I think
there was some bitrot during 2.3 on the cache line usage -- 2.2 pretty
much only needed 2 cache lines in the header for a FF packet) 


-Andi

From owner-netdev@oss.sgi.com Thu Sep 14 08:51:28 2000
Received:  by oss.sgi.com id <S42255AbQINPvT>;
	Thu, 14 Sep 2000 08:51:19 -0700
Received: from robur.slu.se ([130.238.98.12]:20485 "EHLO robur.slu.se")
	by oss.sgi.com with ESMTP id <S42251AbQINPu5>;
	Thu, 14 Sep 2000 08:50:57 -0700
Received: (from robert@localhost) by robur.slu.se (8.8.7/8.8.7) id RAA04917; Thu, 14 Sep 2000 17:50:51 +0200
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: <14784.62427.351923.465024@robur.slu.se>
Date:   Thu, 14 Sep 2000 17:50:51 +0200 (CEST)
To:     "Andi Kleen" <ak@suse.de>
Cc:     Andrew Morton <andrewm@uow.edu.au>, jamal <hadi@cyberus.ca>,
        "David S. Miller" <davem@redhat.com>, jgarzik@mandrakesoft.com,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: Preallocated skb's?
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



Yes !

The FF experiments with 2.1.X indicated improvement factor about 2-3 times
with skb recycling. With combination of FF and skb recycling we could reach 
fast Ethernet wire speed forwarding on 400 Mhz CPU. About ~147 KPPS. 
As jamal reported the improvement is much less today but the forwarding 
performance is impressive even without FF and skb recycling. Slab seems
to do a good job and especially when the debug is disabled. :-)


						--ro

Andi Kleen writes:
 > On Thu, Sep 14, 2000 at 11:59:32PM +1100, Andrew Morton wrote:
 > > That's 20 usec per interrupt, of which 1 usec could be saved by skb
 > > pooling.
 > 
 > FF usually runs with interrupt mitigation at higher rates (8-16 or even
 > more packets / interrupt). I agree though that it probably does not 
 > make too much difference.  alloc_skb could probably be made cheaper 
 > for the FF case by being more clever in the slab constructor (I think
 > there was some bitrot during 2.3 on the cache line usage -- 2.2 pretty
 > much only needed 2 cache lines in the header for a FF packet) 
 > 
 > 
 > -Andi

From owner-netdev@oss.sgi.com Thu Sep 14 13:41:40 2000
Received:  by oss.sgi.com id <S42272AbQINUlV>;
	Thu, 14 Sep 2000 13:41:21 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:40879 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42208AbQINUlG>;
	Thu, 14 Sep 2000 13:41:06 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id QAA25092;
	Thu, 14 Sep 2000 16:40:54 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id QAA08107;
	Thu, 14 Sep 2000 16:40:56 -0400 (EDT)
Date:   Thu, 14 Sep 2000 16:40:55 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     netdev@oss.sgi.com
cc:     "David S. Miller" <davem@redhat.com>,
        Andrew Morton <andrewm@uow.edu.au>, jgarzik@mandrakesoft.com,
        linux-kernel@vger.kernel.org
Subject: Re: Preallocated skb's?
In-Reply-To: <39C0CBB4.D75577A3@uow.edu.au>
Message-ID: <Pine.GSO.4.20.0009141623220.28496-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



What Alexey's code does is _not_ preallocation -- it does re-cycling.
On tx_completion, the skb is recycled onto a recycle queue unless the
queue is full (which is a tunable parameter) in which case it is freed.
This is more sensible than doing pre-allocation during idle times
or other smart schemes. On a busy system this queue will always 
have something.

What i meant by aging is to have a separate thread that prunes the queue
based on age i.e how long the skb has been sitting there etc. I think Jes
had a bottom-half running there; a simple per-cpu timer might suffice.
The heuristic (such as the timer decay etc) for this part needs a study
and thats what Robert and i are planing to do.

cheers,
jamal



From owner-netdev@oss.sgi.com Thu Sep 14 14:07:01 2000
Received:  by oss.sgi.com id <S42208AbQINVGv>;
	Thu, 14 Sep 2000 14:06:51 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:3259 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42197AbQINVGX>;
	Thu, 14 Sep 2000 14:06:23 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id RAA07071;
	Thu, 14 Sep 2000 17:06:22 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id RAA17066;
	Thu, 14 Sep 2000 17:06:23 -0400 (EDT)
Date:   Thu, 14 Sep 2000 17:06:23 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Andrew Morton <andrewm@uow.edu.au>
cc:     "David S. Miller" <davem@redhat.com>, jgarzik@mandrakesoft.com,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: Preallocated skb's?
In-Reply-To: <39C0CBB4.D75577A3@uow.edu.au>
Message-ID: <Pine.GSO.4.20.0009141641040.28496-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 Thu, 14 Sep 2000, Andrew Morton wrote:

> But for 3c59x (which is not a very efficient driver (yet)), it takes 6
> usecs to even get into the ISR, and around 4 uSecs to traverse it. 
> Guess another 4 to leave the ISR, guess half as much again for whoever
> got interrupted to undo the resulting cache pollution.
> 
> That's 20 usec per interrupt, of which 1 usec could be saved by skb
> pooling.
> 

With these numbers + how long it takes to queue the packets in
netif_rx(); i would say you roughly should be able to tune your DMA
ring appropriately. 

Roughly your DMA ring should be able to hold:

(PCI_Burst_bandwidth*((20*10-6)+pci_bus_latency))) bits.

Did i hear Donald say something? ;->

> 
> If you don't do Rx interrupt mitigation there's no point in event
> thinking about skb pooling.
> 

FF does not use mitigation and as Robert was pointing out this was adding
a lot of value.

cheers,
jamal


From owner-netdev@oss.sgi.com Thu Sep 14 14:42:33 2000
Received:  by oss.sgi.com id <S42273AbQINVmN>;
	Thu, 14 Sep 2000 14:42:13 -0700
Received: from battlejitney.wdhq.scyld.com ([216.254.93.178]:10994 "EHLO
        vaio.greennet") by oss.sgi.com with ESMTP id <S42197AbQINVl6>;
	Thu, 14 Sep 2000 14:41:58 -0700
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id RAA32591;
	Thu, 14 Sep 2000 17:42:07 -0400
Date:   Thu, 14 Sep 2000 17:42:07 -0400 (EDT)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     jamal <hadi@cyberus.ca>
cc:     linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: Preallocated skb's?
In-Reply-To: <Pine.GSO.4.20.0009141641040.28496-100000@shell.cyberus.ca>
Message-ID: <Pine.LNX.4.10.10009141723530.1335-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 Thu, 14 Sep 2000, jamal wrote:
> On Thu, 14 Sep 2000, Andrew Morton wrote:
> > But for 3c59x (which is not a very efficient driver (yet)), it takes 6
> > usecs to even get into the ISR, and around 4 uSecs to traverse it. 
> > Guess another 4 to leave the ISR, guess half as much again for whoever
> > got interrupted to undo the resulting cache pollution.
> > 
> > That's 20 usec per interrupt, of which 1 usec could be saved by skb
> > pooling.
> 
> With these numbers + how long it takes to queue the packets in
> netif_rx(); i would say you roughly should be able to tune your DMA
> ring appropriately. 
> 
> Roughly your DMA ring should be able to hold:
> 
> (PCI_Burst_bandwidth*((20*10-6)+pci_bus_latency))) bits.
> 
> Did i hear Donald say something? ;->

No, because I know I sound like a broken record.  <skip><skip>

What we measured is that the cache impact of allocating and initializing our
(ever-larger) skbuffs is huge.  So we pay some CPU time getting a new
skbuff, and some more CPU time later reloading the cache with useful data.

The skbuff is added to the end of the driver Rx buffer list, so the memory
lines are out of the cache by the time we need them.

The Rx ring should be able to hold at least
   (interrupt-latency * 100/1000Mbps) bits
and 
   (interrupt-latency * 100/1000Mbps)/(64 bytes/packet * 8 bits/byte) packets


> > If you don't do Rx interrupt mitigation there's no point in event
> > thinking about skb pooling.
> 
> FF does not use mitigation and as Robert was pointing out this was adding
> a lot of value.

The PCI drivers make some effort to always allocate the same size skbuff, so
recycling skbuffs, or otherwise optimizing their allocation, is useful.

The only significant advantage of interrupt mitigation is cache locality
when allocating new skbuffs, and having an additional mechanism to drop
packets under overwhelming load.

The disadvantage of Rx interrupt mitigation is adding latency just where it
might matter the most.  Remember that the hot ticket for old-IPX performance
was taking an *extra* early interrupt for each Rx packet.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf-II Cluster Distribution
Annapolis MD 21403


From owner-netdev@oss.sgi.com Thu Sep 14 19:26:43 2000
Received:  by oss.sgi.com id <S42299AbQIOC0X>;
	Thu, 14 Sep 2000 19:26:23 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:52384 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42226AbQIOC0N>;
	Thu, 14 Sep 2000 19:26:13 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id WAA26265;
	Thu, 14 Sep 2000 22:26:08 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id WAA08107;
	Thu, 14 Sep 2000 22:26:08 -0400 (EDT)
Date:   Thu, 14 Sep 2000 22:26:08 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Donald Becker <becker@scyld.com>
cc:     linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: Preallocated skb's?
In-Reply-To: <Pine.LNX.4.10.10009141723530.1335-100000@vaio.greennet>
Message-ID: <Pine.GSO.4.20.0009142212110.25283-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 Thu, 14 Sep 2000, Donald Becker wrote:

> No, because I know I sound like a broken record.  <skip><skip> 

;->

> What we measured is that the cache impact of allocating and initializing our
> (ever-larger) skbuffs is huge.  So we pay some CPU time getting a new
> skbuff, and some more CPU time later reloading the cache with useful data.
> 
> The skbuff is added to the end of the driver Rx buffer list, so the memory
> lines are out of the cache by the time we need them.

So is there a workable solution to this?

> 
> The Rx ring should be able to hold at least
>    (interrupt-latency * 100/1000Mbps) bits
> and 
>    (interrupt-latency * 100/1000Mbps)/(64 bytes/packet * 8 bits/byte) packets
> 

cool. Assuming 64 bytes because it is minimal sized ethernet packet?

> The PCI drivers make some effort to always allocate the same size skbuff, so
> recycling skbuffs, or otherwise optimizing their allocation, is useful.
> 

Good to hear this from you.

> The only significant advantage of interrupt mitigation is cache locality
> when allocating new skbuffs, and having an additional mechanism to drop
> packets under overwhelming load.
> 
> The disadvantage of Rx interrupt mitigation is adding latency just where it
> might matter the most.  

One of the things we need to measure still is the latency. The scheme
currently used with dynamically adjusting the mitigation parameters might
not affect latency much -- simply because the adjustement is based on the
load. We still have to prove this. The theory is:
Under a lot of congestion, you delay longer because the layers above
you are congested as gauged from a feedback; and under low congestion, you
should theoretically adjust all the way down to 1 interupt/packet. Under
heavy load, your latency is already screwed anyways because of large
backlog queue; this is regardless of mitigation.

> Remember that the hot ticket for old-IPX performance
> was taking an *extra* early interrupt for each Rx packet.

If i remember correctly some of the 3coms still give this 'mid-interupt',
no? It could useful to just say quickly read the header and make routing
decisions as in fast routing but not under heavy load.

cheers,
jamal


From owner-netdev@oss.sgi.com Thu Sep 14 19:41:03 2000
Received:  by oss.sgi.com id <S42331AbQIOCkn>;
	Thu, 14 Sep 2000 19:40:43 -0700
Received: from hq.fsmlabs.com ([209.155.42.197]:32777 "EHLO hq.fsmlabs.com")
	by oss.sgi.com with ESMTP id <S42226AbQIOCkZ>;
	Thu, 14 Sep 2000 19:40:25 -0700
Received: (from yodaiken@localhost)
	by hq.fsmlabs.com (8.9.3/8.9.3) id UAA10220;
	Thu, 14 Sep 2000 20:36:32 -0600
Date:   Thu, 14 Sep 2000 20:36:32 -0600
From:   yodaiken@fsmlabs.com
To:     jamal <hadi@cyberus.ca>
Cc:     Donald Becker <becker@scyld.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: Preallocated skb's?
Message-ID: <20000914203632.A10166@hq.fsmlabs.com>
References: <Pine.LNX.4.10.10009141723530.1335-100000@vaio.greennet> <Pine.GSO.4.20.0009142212110.25283-100000@shell.cyberus.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <Pine.GSO.4.20.0009142212110.25283-100000@shell.cyberus.ca>; from jamal on Thu, Sep 14, 2000 at 10:26:08PM -0400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Thu, Sep 14, 2000 at 10:26:08PM -0400, jamal wrote:
> 
> 
> One of the things we need to measure still is the latency. The scheme
> currently used with dynamically adjusting the mitigation parameters might
> not affect latency much -- simply because the adjustement is based on the
> load. We still have to prove this. The theory is:
> Under a lot of congestion, you delay longer because the layers above
> you are congested as gauged from a feedback; and under low congestion, you
> should theoretically adjust all the way down to 1 interupt/packet. Under
> heavy load, your latency is already screwed anyways because of large
> backlog queue; this is regardless of mitigation.

Or maybe the extra delay in congested circumstances will cause more 
timeouts and that's precisely when you need to improve latency?


-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com


From owner-netdev@oss.sgi.com Fri Sep 15 03:08:52 2000
Received:  by oss.sgi.com id <S42367AbQIOKIc>;
	Fri, 15 Sep 2000 03:08:32 -0700
Received: from mail.iwr.uni-heidelberg.de ([129.206.104.30]:61165 "EHLO
        mail.iwr.uni-heidelberg.de") by oss.sgi.com with ESMTP
	id <S42361AbQIOKIY>; Fri, 15 Sep 2000 03:08:24 -0700
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.9.3/8.9.3) with ESMTP id MAA25605;
	Fri, 15 Sep 2000 12:08:15 +0200 (MET DST)
Received: from localhost (bogdan@localhost)
	by kenzo.iwr.uni-heidelberg.de (8.9.3/8.9.3) with ESMTP id MAA14586;
	Fri, 15 Sep 2000 12:08:10 +0200
Date:   Fri, 15 Sep 2000 12:08:10 +0200 (CEST)
From:   Bogdan Costescu <Bogdan.Costescu@IWR.Uni-Heidelberg.De>
To:     jamal <hadi@cyberus.ca>
cc:     Donald Becker <becker@scyld.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com, Andrew Morton <andrewm@uow.edu.au>
Subject: Re: Preallocated skb's?
In-Reply-To: <Pine.GSO.4.20.0009142212110.25283-100000@shell.cyberus.ca>
Message-ID: <Pine.LNX.4.21.0009151149430.14236-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 Thu, 14 Sep 2000, jamal wrote:

> If i remember correctly some of the 3coms still give this 'mid-interupt',
> no? It could useful to just say quickly read the header and make routing
> decisions as in fast routing but not under heavy load.

The 3Com cards can generate this interrupt, however this is not used in
current 3c59x.c. I suggested this to Andrew, but he is already worried
about the current interrupt rate and unhappy that 3Com cards do not
provide hardware support for Rx mitigation.

An ideea might be to combine Rx early interrupts with some kind of
software timer-based mitigation. IMHO this has 2 advantages:
- because of the overhead that Andrew pointed out, by the time the CPU
reaches the ISR code and the skbuff allocation is done, the entire packet
might already be transferred; however, a check has to be done to assure
that the packet was not dropped by the hardware and you try to fit a
packet in a skbuff sized for the previous packet (in case several packets
can be transferred during the "overhead" time)
- under load, because interrupts occur anyway (the Rx early ones), you
don't loose anything in terms of latency.

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 Sep 15 06:02:14 2000
Received:  by oss.sgi.com id <S42370AbQIONCE>;
	Fri, 15 Sep 2000 06:02:04 -0700
Received: from krusty.E-Technik.Uni-Dortmund.DE ([129.217.163.1]:57864 "HELO convert rfc822-to-8bit
        krusty.e-technik.uni-dortmund.de") by oss.sgi.com with SMTP
	id <S42368AbQIONBn>; Fri, 15 Sep 2000 06:01:43 -0700
Received: from emma1.emma.line.org (krusty.e-technik.uni-dortmund.de [129.217.163.1])
	by krusty.e-technik.uni-dortmund.de (Postfix) with ESMTP
	id B2F85A3875; Fri, 15 Sep 2000 15:01:39 +0200 (CEST)
Received: by emma1.emma.line.org (Postfix, from userid 500)
	id 530EAA2076; Fri, 15 Sep 2000 15:01:25 +0200 (CEST)
Date:   Fri, 15 Sep 2000 15:01:25 +0200
From:   Matthias Andree <matthias.andree@stud.uni-dortmund.de>
To:     linux-kernel@vger.kernel.org
Cc:     dns@list.cr.yp.to, davem@redhat.com, ak@muc.de,
        kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com,
        Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
Message-ID: <20000915150125.A8057@emma1.emma.line.org>
Mail-Followup-To: linux-kernel@vger.kernel.org, dns@list.cr.yp.to,
	davem@redhat.com, ak@muc.de, kuznet@ms2.inr.ac.ru,
	netdev@oss.sgi.com, Alan Cox <alan@lxorguk.ukuu.org.uk>
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
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Please mind the To: and Cc: headers. If there are relevant followups,
please send me a Cc: as I'm only subscribed to the linux-kernel and dns
mailing lists.

In some debugging, Pavel Kankovsky and Daniel J. Bernstein have tracked
down a Linux Kernel bug that I can confirm for 2.2.17 and 2.4.0-test8 (I
did not try 2.0.38, don't have gcc 2.7.2.3 installed). I have copies of
their mail (without Received: headers) available (see below).

BUG DESCRIPTION:
  (This is for IPv4, someone would have to check IPv6 as well).
  The socket flag O_NONBLOCK is _NOT_ properly inherited through an
  accept(2) call, in spite of what socket(7) documents. This is a bug.
  accept(2) must copy the file descriptor's flag of the socket.

SOCKET(7) EXCERPT: (from man pages 1.31)
  It is possible to do non-blocking IO on sockets by setting the
  O_NONBLOCK  flag  on  a  socket file descriptor using fcntl(2).
  O_NONBLOCK  is  inherited  through  an  accept.  Then  all  operations
  that would normally block will (usu­ ally) return  with  EAGAIN;
  connect(2)  returns  an  EIN­ PROGRESS  error  in this case.  The user
  can then wait for various events via poll(2) or select(2).

EXAMPLE:
  At http://home.pages.de/~mandree/socktest.c, there is a small test
  program (3 kB) that is not really portable, and that relies on
  dnscache for library functions (it's a quick hack). 
  
  Build it on Linux 2.2 or Linux 2.4.0-test8 and see this: (I'm running
  ./socktest 1234 & telnet localhost 1234)

  options on socket (fd=3): O_NONBLOCK 
  options after accept (fd=6): 
  accepted from 127.0.0.1:1068

  It SHOULD be: (FreeBSD 4.0 gets it right):
  options on socket (fd=3): O_NONBLOCK 
  options after accept (fd=4): O_NONBLOCK 
  accepted from 127.0.0.1:1053

  To compile the program on FreeBSD 4, comment out the line with O_SYNC
  and insert #include <poll.h>; compilation instructions are at the head
  of that file.

REFERENCES:
  test program is at
    http://home.pages.de/~mandree/socktest.c
  dnscache source code is at
    http://cr.yp.to/djbdns/dnscache-1.00.tar.gz (78 kB).
  Pavel's mail is at
    http://home.pages.de/~mandree/20000904102753.2572.0%40argo.troja.mff.cuni.cz
  Dan's mail is at
    http://home.pages.de/~mandree/20000904193940.20671.qmail%40cr.yp.to

-- 
Matthias Andree

From owner-netdev@oss.sgi.com Fri Sep 15 06:08:35 2000
Received:  by oss.sgi.com id <S42371AbQIONIP>;
	Fri, 15 Sep 2000 06:08:15 -0700
Received: from pizda.ninka.net ([216.101.162.242]:53666 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42368AbQIONHy>;
	Fri, 15 Sep 2000 06:07:54 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id FAA09729;
	Fri, 15 Sep 2000 05:54:14 -0700
Date:   Fri, 15 Sep 2000 05:54:14 -0700
Message-Id: <200009151254.FAA09729@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     matthias.andree@stud.uni-dortmund.de
CC:     linux-kernel@vger.kernel.org, dns@list.cr.yp.to, ak@muc.de,
        kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, alan@lxorguk.ukuu.org.uk
In-reply-to: <20000915150125.A8057@emma1.emma.line.org> (message from Matthias
	Andree on Fri, 15 Sep 2000 15:01:25 +0200)
Subject: Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
References:  <20000915150125.A8057@emma1.emma.line.org>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date: Fri, 15 Sep 2000 15:01:25 +0200
   From: Matthias Andree <matthias.andree@stud.uni-dortmund.de>

     (This is for IPv4, someone would have to check IPv6 as well).
     The socket flag O_NONBLOCK is _NOT_ properly inherited through an
     accept(2) call, in spite of what socket(7) documents. This is a bug.
     accept(2) must copy the file descriptor's flag of the socket.

The socket(7) manpage is buggy, not the kernel.

This has been this way forever, it is thus an API and it is not
changing.  Changing it would break existing programs.  End of story.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Fri Sep 15 06:18:45 2000
Received:  by oss.sgi.com id <S42372AbQIONSe>;
	Fri, 15 Sep 2000 06:18:34 -0700
Received: from Cantor.suse.de ([194.112.123.193]:49928 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42368AbQIONSQ>;
	Fri, 15 Sep 2000 06:18:16 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 6408E1E324; Fri, 15 Sep 2000 15:18:14 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id CEB9F10A02A; Fri, 15 Sep 2000 15:18:13 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 68D082F300; Fri, 15 Sep 2000 15:18:05 +0200 (MEST)
Date:   Fri, 15 Sep 2000 15:18:05 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     "David S. Miller" <davem@redhat.com>
Cc:     matthias.andree@stud.uni-dortmund.de, linux-kernel@vger.kernel.org,
        dns@list.cr.yp.to, ak@muc.de, kuznet@ms2.inr.ac.ru,
        netdev@oss.sgi.com, alan@lxorguk.ukuu.org.uk
Subject: Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
Message-ID: <20000915151805.A4667@gruyere.muc.suse.de>
References: <20000915150125.A8057@emma1.emma.line.org> <200009151254.FAA09729@pizda.ninka.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200009151254.FAA09729@pizda.ninka.net>; from davem@redhat.com on Fri, Sep 15, 2000 at 05:54:14AM -0700
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, Sep 15, 2000 at 05:54:14AM -0700, David S. Miller wrote:
>    Date: Fri, 15 Sep 2000 15:01:25 +0200
>    From: Matthias Andree <matthias.andree@stud.uni-dortmund.de>
> 
>      (This is for IPv4, someone would have to check IPv6 as well).
>      The socket flag O_NONBLOCK is _NOT_ properly inherited through an
>      accept(2) call, in spite of what socket(7) documents. This is a bug.
>      accept(2) must copy the file descriptor's flag of the socket.
> 
> The socket(7) manpage is buggy, not the kernel.

Fixed on vger now.

I planned to send an update to Andries soon anyways.


-Andi

From owner-netdev@oss.sgi.com Fri Sep 15 06:33:04 2000
Received:  by oss.sgi.com id <S42374AbQIONcp>;
	Fri, 15 Sep 2000 06:32:45 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:62631 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42368AbQIONcR>;
	Fri, 15 Sep 2000 06:32:17 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id JAA15330;
	Fri, 15 Sep 2000 09:32:11 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id JAA27381;
	Fri, 15 Sep 2000 09:32:11 -0400 (EDT)
Date:   Fri, 15 Sep 2000 09:32:10 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Bogdan Costescu <Bogdan.Costescu@IWR.Uni-Heidelberg.De>
cc:     Donald Becker <becker@scyld.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com, Andrew Morton <andrewm@uow.edu.au>
Subject: Re: Preallocated skb's?
In-Reply-To: <Pine.LNX.4.21.0009151149430.14236-100000@kenzo.iwr.uni-heidelberg.de>
Message-ID: <Pine.GSO.4.20.0009150854430.12133-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 Fri, 15 Sep 2000, Bogdan Costescu wrote:

> On Thu, 14 Sep 2000, jamal wrote:
> 
> The 3Com cards can generate this interrupt, however this is not used in
> current 3c59x.c. I suggested this to Andrew, but he is already worried
> about the current interrupt rate and unhappy that 3Com cards do not
> provide hardware support for Rx mitigation.
> 
> An ideea might be to combine Rx early interrupts with some kind of
> software timer-based mitigation. 

Only the timer runs at HZ granularity ;-<

>  IMHO this has 2 advantages:
> - because of the overhead that Andrew pointed out, by the time the CPU
> reaches the ISR code and the skbuff allocation is done, the entire packet
> might already be transferred; 

20Msec is probably too much time. If my math is not wrong, 1 bit time in
a 100Mps is 1 ns; 64 bytes is 512ns. If you are waiting for 640 bytes
more that is ~5 microsecs or say 10microsecs for average 1000 bytes
in a LAN. For a 10mbps connection ~100microsecs. But we dont have problems
with 10Mbps.
I think this is an interesting heuristic to use. the 20Msec given by
Andrew appears to me to be x86 specific and processor dependent though.
Can you guarantee it on a 600Mhz Alpha processor?
This is just one of those schemes which are useful in my opinion for
quick header inspection: While the packet is still coming in, you have
enough data to make a call. You use the period(5-10micros), while waiting
for full packet arrival, to make the route decision (lookup etc).
i.e this will allow for a better FF; it will not offload things.
Instead of using full-rx interupts as is done today, it will make sense to
receive mid-interupts so that you are ready for the above scheme. I know,
i know Linux is a general purpose OS.

> however, a check has to be done to assure
> that the packet was not dropped by the hardware and you try to fit a
> packet in a skbuff sized for the previous packet (in case several packets
> can be transferred during the "overhead" time)

Most of the schemes like that dont drop the packet once you receive
partial pieces. Other incoming packets will be dropped though if no space.

cheers,
jamal


From owner-netdev@oss.sgi.com Fri Sep 15 06:40:04 2000
Received:  by oss.sgi.com id <S42375AbQIONjo>;
	Fri, 15 Sep 2000 06:39:44 -0700
Received: from TSX-PRIME.MIT.EDU ([18.86.0.76]:8073 "HELO tsx-prime.MIT.EDU")
	by oss.sgi.com with SMTP id <S42368AbQIONje>;
	Fri, 15 Sep 2000 06:39:34 -0700
Received: by tsx-prime.MIT.EDU 
	with sendmail-SMI-8.6/1.2, id JAA15073; Fri, 15 Sep 2000 09:38:36 -0400
Date:   Fri, 15 Sep 2000 09:38:36 -0400
Message-Id: <200009151338.JAA15073@tsx-prime.MIT.EDU>
From:   "\"Theodore Y. Ts'o\" <tytso@mit.edu> To: Matthias Andree" 
        <tytso@MIT.EDU>
CC:     linux-kernel@vger.kernel.org, dns@list.cr.yp.to, davem@redhat.com,
        ak@muc.de, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com,
        Alan Cox <alan@lxorguk.ukuu.org.uk>
In-reply-to: Matthias Andree's message of Fri, 15 Sep 2000 15:01:25 +0200,
	<20000915150125.A8057@emma1.emma.line.org>
Subject: Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
Phone:  (781) 391-3464
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date: 	Fri, 15 Sep 2000 15:01:25 +0200
   From: Matthias Andree <matthias.andree@stud.uni-dortmund.de>

   BUG DESCRIPTION:
     (This is for IPv4, someone would have to check IPv6 as well).
     The socket flag O_NONBLOCK is _NOT_ properly inherited through an
     accept(2) call, in spite of what socket(7) documents. This is a bug.
     accept(2) must copy the file descriptor's flag of the socket.

Yes, it's true that BSD apparently has this behaviour.  The problem is
that there are existing Linux programs that are fairly widely deployed
that would break if we made this change now.  And even if we did make
the change, the existing deployed 2.2 kernels, which represents a huge
installed base, would still be around for a long time.

BSD'er's can kvetch about our not following "the BSD sockets interface".
I'd be a lot more sympathetic if the CSRG had bothered to actually write
it down as a formal specification, and if the CSRG themselves didn't
make random, not-always-backwards-compatible changes to the interfaces
from 4.3, 4.3Reno, 4.3Tahoe, and 4.4.  Oh, well.

My suggestion is to document that if you want a well-written, portable
program, you must set the file descriptor flags after an accept(2) call.
It's not ideal, but it's the best way to make sure your application
program will run on the widest possible array of systems.  No, this is
not ideal.  But it's life.

							- Ted


From owner-netdev@oss.sgi.com Fri Sep 15 06:58:05 2000
Received:  by oss.sgi.com id <S42376AbQION5p>;
	Fri, 15 Sep 2000 06:57:45 -0700
Received: from krusty.E-Technik.Uni-Dortmund.DE ([129.217.163.1]:30985 "HELO
        krusty.e-technik.uni-dortmund.de") by oss.sgi.com with SMTP
	id <S42368AbQION5g>; Fri, 15 Sep 2000 06:57:36 -0700
Received: from emma1.emma.line.org (krusty.e-technik.uni-dortmund.de [129.217.163.1])
	by krusty.e-technik.uni-dortmund.de (Postfix) with ESMTP
	id B193EA3891; Fri, 15 Sep 2000 15:57:33 +0200 (CEST)
Received: by emma1.emma.line.org (Postfix, from userid 500)
	id C4B1AA2076; Fri, 15 Sep 2000 15:57:32 +0200 (CEST)
Date:   Fri, 15 Sep 2000 15:57:32 +0200
From:   Matthias Andree <matthias.andree@stud.uni-dortmund.de>
To:     "David S. Miller" <davem@redhat.com>
Cc:     linux-kernel@vger.kernel.org, dns@list.cr.yp.to, netdev@oss.sgi.com
Subject: Re: No Bug: accept discards socket options/O_NONBLOCK
Message-ID: <20000915155731.A8677@emma1.emma.line.org>
Mail-Followup-To: "David S. Miller" <davem@redhat.com>,
	linux-kernel@vger.kernel.org, dns@list.cr.yp.to, netdev@oss.sgi.com
References: <20000915150125.A8057@emma1.emma.line.org> <200009151254.FAA09729@pizda.ninka.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200009151254.FAA09729@pizda.ninka.net>; from davem@redhat.com on Fri, Sep 15, 2000 at 05:54:14 -0700
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, 15 Sep 2000, David S. Miller wrote:

[accept not inheriting O_NONBLOCK]
> The socket(7) manpage is buggy, not the kernel.
> 
> This has been this way forever, it is thus an API and it is not
> changing.  Changing it would break existing programs.  End of story.

I have been looking through the Single Unix Specification v7 and various
accept(2) man pages (NetBSD 1.3, SunOS 4.1.3, SunOS 5.7) and all go like
this: 

"creates a new socket with the same properties as s." "creates a new
file descriptor." - no mention if that has the same O_ flags as the
listening socket.

So it seems that BSD and Solaris 7 happen to copy the fd options as
well, and Linux happens to just create a new fd, and both are right.

Now, interpreting properties as "socket properties", and O_NONBLOCK
being a file descriptor property, it may be legal to not copy the fd
flags.

However, this makes Linux incompatible with *BSD and Solaris, so I'm
wondering what this "break existing programs" would be, portable
programs would most likely not break by the API change. 

Break portability, that's what it actually does, regardless of who is
correct. *sigh*

-- 
Matthias Andree

From owner-netdev@oss.sgi.com Fri Sep 15 07:15:05 2000
Received:  by oss.sgi.com id <S42378AbQIOOOp>;
	Fri, 15 Sep 2000 07:14:45 -0700
Received: from pizda.ninka.net ([216.101.162.242]:37027 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42368AbQIOOOV>;
	Fri, 15 Sep 2000 07:14:21 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id HAA09979;
	Fri, 15 Sep 2000 07:01:32 -0700
Date:   Fri, 15 Sep 2000 07:01:32 -0700
Message-Id: <200009151401.HAA09979@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     matthias.andree@stud.uni-dortmund.de
CC:     linux-kernel@vger.kernel.org, dns@list.cr.yp.to, netdev@oss.sgi.com
In-reply-to: <20000915155731.A8677@emma1.emma.line.org> (message from Matthias
	Andree on Fri, 15 Sep 2000 15:57:32 +0200)
Subject: Re: No Bug: accept discards socket options/O_NONBLOCK
References: <20000915150125.A8057@emma1.emma.line.org> <200009151254.FAA09729@pizda.ninka.net> <20000915155731.A8677@emma1.emma.line.org>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date: Fri, 15 Sep 2000 15:57:32 +0200
   From: Matthias Andree <matthias.andree@stud.uni-dortmund.de>

   However, this makes Linux incompatible with *BSD and Solaris, so
   I'm wondering what this "break existing programs" would be,
   portable programs would most likely not break by the API change.

Every Linux inetd in the world would instantly stop working.

The behavior is not changing, lets end this thread right now.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Fri Sep 15 07:53:55 2000
Received:  by oss.sgi.com id <S42380AbQIOOxf>;
	Fri, 15 Sep 2000 07:53:35 -0700
Received: from mail.iwr.uni-heidelberg.de ([129.206.104.30]:47086 "EHLO
        mail.iwr.uni-heidelberg.de") by oss.sgi.com with ESMTP
	id <S42377AbQIOOxb>; Fri, 15 Sep 2000 07:53:31 -0700
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.9.3/8.9.3) with ESMTP id QAA27918;
	Fri, 15 Sep 2000 16:53:22 +0200 (MET DST)
Received: from localhost (bogdan@localhost)
	by kenzo.iwr.uni-heidelberg.de (8.9.3/8.9.3) with ESMTP id QAA17837;
	Fri, 15 Sep 2000 16:53:21 +0200
Date:   Fri, 15 Sep 2000 16:53:21 +0200 (CEST)
From:   Bogdan Costescu <Bogdan.Costescu@IWR.Uni-Heidelberg.De>
To:     jamal <hadi@cyberus.ca>
cc:     Donald Becker <becker@scyld.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com, Andrew Morton <andrewm@uow.edu.au>
Subject: Re: Preallocated skb's?
In-Reply-To: <Pine.GSO.4.20.0009150854430.12133-100000@shell.cyberus.ca>
Message-ID: <Pine.LNX.4.21.0009151547010.14236-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, 15 Sep 2000, jamal wrote:

> Only the timer runs at HZ granularity ;-<

Some cards provide their own high resolution timers; latest 3Com cards
provide several with different purposes (none currently used). The
question is how many of these also provide the Rx early interrupts.
You also mentioned an auto-tunable Rx mitigation scheme. How do you
implement it without using hardware timers ?

> 20Msec is probably too much time. If my math is not wrong, 1 bit time in
> a 100Mps is 1 ns; 64 bytes is 512ns.

I think your are wrong by a factor of 10 here, 1 bit time at 100Mbps
should be 10 ns. Then 64 bytes is 5.12 us (u=micro). Anyway, this is
comparable with the time needed to reach ISR, so you can have several
(but small number) of packets already waiting for processing.

> You use the period(5-10micros), while waiting
> for full packet arrival, to make the route decision (lookup etc).
> i.e this will allow for a better FF; it will not offload things.

Just that you span several layers by doing this, it's not driver specific
anymore.

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 Sep 15 09:36:16 2000
Received:  by oss.sgi.com id <S42379AbQIOQf4>;
	Fri, 15 Sep 2000 09:35:56 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:17930 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42368AbQIOQfY>;
	Fri, 15 Sep 2000 09:35:24 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA15105; Fri, 15 Sep 2000 20:34:35 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200009151634.UAA15105@ms2.inr.ac.ru>
Subject: Re: [2.4][2.2] Bug: accept discards socket options/O_NONBLOCK
To:     davem@redhat.com (David S. Miller)
Date:   Fri, 15 Sep 2000 20:34:35 +0400 (MSK DST)
Cc:     matthias.andree@stud.uni-dortmund.de, linux-kernel@vger.kernel.org,
        dns@list.cr.yp.to, ak@muc.de, netdev@oss.sgi.com,
        alan@lxorguk.ukuu.org.uk
In-Reply-To: <200009151254.FAA09729@pizda.ninka.net> from "David S. Miller" at Sep 15, 0 05:54:14 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 224       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> This has been this way forever, it is thus an API and it is not
> changing.  Changing it would break existing programs.  End of story.

8) However, imagine, freebsd folks changed this in their release 2.x.

Alexey

From owner-netdev@oss.sgi.com Fri Sep 15 09:38:57 2000
Received:  by oss.sgi.com id <S42389AbQIOQir>;
	Fri, 15 Sep 2000 09:38:47 -0700
Received: from pacific.usatoday.com ([167.8.29.64]:26672 "HELO
        mail9.usatoday.com") by oss.sgi.com with SMTP id <S42368AbQIOQid>;
	Fri, 15 Sep 2000 09:38:33 -0700
Received: (qmail 27230 invoked by uid 1000); 15 Sep 2000 16:38:35 -0000
Date:   Fri, 15 Sep 2000 12:38:35 -0400
From:   Raul Miller <raul@usatoday.com>
To:     "David S. Miller" <davem@redhat.com>
Cc:     matthias.andree@stud.uni-dortmund.de, linux-kernel@vger.kernel.org,
        dns@list.cr.yp.to, netdev@oss.sgi.com
Subject: Re: No Bug: accept discards socket options/O_NONBLOCK
Message-ID: <20000915123835.A26973@usatoday.com>
References: <20000915150125.A8057@emma1.emma.line.org> <200009151254.FAA09729@pizda.ninka.net> <20000915155731.A8677@emma1.emma.line.org> <200009151401.HAA09979@pizda.ninka.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <200009151401.HAA09979@pizda.ninka.net>; from davem@redhat.com on Fri, Sep 15, 2000 at 07:01:32AM -0700
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, Sep 15, 2000 at 07:01:32AM -0700, David S. Miller wrote:
> Every Linux inetd in the world would instantly stop working.

Pointer to docs on why this is not considered a bug in inetd?

Also, you already know how to upgrade a syscall without breaking backwards
compatability.

> The behavior is not changing, lets end this thread right now.

I'm not trying to say the behavior must change -- I'm trying to find out
why it won't.  ["I don't see the need", is something that I'd accept.
However, "it would break inetd" doesn't make sense.]

-- 
Raul

From owner-netdev@oss.sgi.com Fri Sep 15 14:22:00 2000
Received:  by oss.sgi.com id <S42394AbQIOVVl>;
	Fri, 15 Sep 2000 14:21:41 -0700
Received: from battlejitney.wdhq.scyld.com ([216.254.93.178]:506 "EHLO
        vaio.greennet") by oss.sgi.com with ESMTP id <S42366AbQIOVVQ>;
	Fri, 15 Sep 2000 14:21:16 -0700
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id QAA03005;
	Fri, 15 Sep 2000 16:41:53 -0400
Date:   Fri, 15 Sep 2000 16:41:53 -0400 (EDT)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     Bogdan Costescu <Bogdan.Costescu@IWR.Uni-Heidelberg.De>
cc:     jamal <hadi@cyberus.ca>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com, Andrew Morton <andrewm@uow.edu.au>
Subject: Re: Preallocated skb's?
In-Reply-To: <Pine.LNX.4.21.0009151547010.14236-100000@kenzo.iwr.uni-heidelberg.de>
Message-ID: <Pine.LNX.4.10.10009151407580.1335-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 Fri, 15 Sep 2000, Bogdan Costescu wrote:

> On Fri, 15 Sep 2000, jamal wrote:
> > You use the period(5-10micros), while waiting
> > for full packet arrival, to make the route decision (lookup etc).
> > i.e this will allow for a better FF; it will not offload things.
> 
> Just that you span several layers by doing this, it's not driver specific
> anymore.

Many chips have some sort of early-Rx feature, but it's still a bad idea for
the many reasons I've pointed out before.

An additional reason not use early-Rx is that chips such as the 3c905C are
most efficient at using the PCI bus when transfering a whole packet in a
single PCI burst (plus two smaller bursts initially reading and later
writing the descriptor).  Using an early-Rx interrupt scheme means using
multiple smaller bursts.

The early-Rx scheme worked well on the ISA bus, where transfers were slow
and not bursting.

Also note: it is possible to drop an Rx packet after the early Rx
interrupt.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf-II Cluster Distribution
Annapolis MD 21403


From owner-netdev@oss.sgi.com Sat Sep 16 07:50:20 2000
Received:  by oss.sgi.com id <S42409AbQIPOuK>;
	Sat, 16 Sep 2000 07:50:10 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:63147 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42403AbQIPOuK>;
	Sat, 16 Sep 2000 07:50:10 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id KAA26940;
	Sat, 16 Sep 2000 10:49:59 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id KAA19668;
	Sat, 16 Sep 2000 10:49:54 -0400 (EDT)
Date:   Sat, 16 Sep 2000 10:49:53 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Bogdan Costescu <Bogdan.Costescu@IWR.Uni-Heidelberg.De>
cc:     Donald Becker <becker@scyld.com>, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com, Andrew Morton <andrewm@uow.edu.au>
Subject: Re: Preallocated skb's?
In-Reply-To: <Pine.LNX.4.21.0009151547010.14236-100000@kenzo.iwr.uni-heidelberg.de>
Message-ID: <Pine.GSO.4.20.0009161028460.11609-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 Fri, 15 Sep 2000, Bogdan Costescu wrote:

> On Fri, 15 Sep 2000, jamal wrote:
> 
> > Only the timer runs at HZ granularity ;-<
> 
> Some cards provide their own high resolution timers; latest 3Com cards
> provide several with different purposes (none currently used). The
> question is how many of these also provide the Rx early interrupts.
> You also mentioned an auto-tunable Rx mitigation scheme. How do you
> implement it without using hardware timers ?
> 

Oh, the tulip 21143 explicitly has an interupt mitigation timer; this is
for both the tx and rx. But i see you can also use a general purpose timer
on the NIC to simulate mitigation.
disable rx interupts and other sources of noise (eg rx no buf) and set the
timer to wait a certain number of packet times.
Donald's drivers generally have this scheme built in; however, it is a
one-shot mode on rx work overload (mostly there for interupt sharing
according to one of Donald's old posts).
So what you do instead is have a table of these 'mitigation' values[1]
and select the appropriate mitigation value; i.e you have a pointer that
moves up and down the table and based on the load picks the correct
mitigation value.
When Robert Oks the current tulip, you should be able to see how it is
done there.

> > 20Msec is probably too much time. If my math is not wrong, 1 bit time in
> > a 100Mps is 1 ns; 64 bytes is 512ns.
> 
> I think your are wrong by a factor of 10 here, 1 bit time at 100Mbps
> should be 10 ns. Then 64 bytes is 5.12 us (u=micro). Anyway, this is
> comparable with the time needed to reach ISR, so you can have several
> (but small number) of packets already waiting for processing.
> 
> > You use the period(5-10micros), while waiting
> > for full packet arrival, to make the route decision (lookup etc).
> > i.e this will allow for a better FF; it will not offload things.
> 
> Just that you span several layers by doing this, it's not driver specific
> anymore.

I think we should heed Donald's advice on this early rx. I would take
Donald's word for it; he's been there done that. He knows.
eg the PCI burst issues makes a lot of sense. Unless someone with the
right tools (eg PCI bus monitors) might do some measurements and maybe
challenge Donald ;->

cheers,
jamal

[1] the table would look something like:
table[0] == 1 packet per interupt (default); disable timer
table[1] == 2 packets per interupt
table[3] == 3 packets per interupt 
.
.
etc.
use 64 bytes as the packet size since it is the smallest ethernet size.
as you pointed out that is 51.2 microsecs. so 102.4 microsecs for table[1]



From owner-netdev@oss.sgi.com Sat Sep 16 14:50:23 2000
Received:  by oss.sgi.com id <S42411AbQIPVuN>;
	Sat, 16 Sep 2000 14:50:13 -0700
Received: from kogge.hanse.de ([192.76.134.17]:60689 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S42403AbQIPVuB>;
	Sat, 16 Sep 2000 14:50:01 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id XAA68638;
	Sat, 16 Sep 2000 23:54:32 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id WAA01014;
	Sat, 16 Sep 2000 22:48:49 +0200
Date:   Sat, 16 Sep 2000 22:48:49 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200009162048.WAA01014@baty.hanse.de>
To:     kuznet@ms2.inr.ac.ru
CC:     alan@lxorguk.ukuu.org.uk, davem@redhat.com,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
In-reply-to: <200009161729.VAA28483@ms2.inr.ac.ru> (kuznet@ms2.inr.ac.ru)
Subject: Re: Q: sock output serialization
References:  <200009161729.VAA28483@ms2.inr.ac.ru>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Hi,

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

    kuznet> Hello!
    >> scheduler may re-order frames

    kuznet> It cannot, provided sender holds order until
    kuznet> dev_queue_xmit().

But if I set different skb->priority? ;) Well that would be my fault than .. 

    >> or drop them.

    kuznet> Yes. And if you share _single_ device both for reliable
    kuznet> and unreliable services, you have to make special tricks.

Well, I think this problem will not occur. For shared service, we
will use a datalink protocol running above netif. (e.g. mixed X.25
and IP over ethernet where X.25 runs on top of 802.2 LLC.2 which
will be implemented above netif). And for smart (firmware lapb)
interfaces, which are the real problem, we won´t need to support
shared service.

    >> be fixed by providing a special LAPB network scheduler which
    >> takes care about preserving reliable LAPB semantics.

    kuznet> Yes. ATM CLIP already does this, look at atm clip.c and
    kuznet> sch_atm.c to get an example.

Yes. But the above seems to be a network scheduler specialized
for passing IP down to an ATM tunnel. What I had in mind would
correspond to a special scheduler for an atm net_device (but ATM
does not use stadard linux net_device).   

    >> that value before calling netif_rx().  Then upper layer´s
    >> worried about netif_rx() re-ordering can detect this and act
    >> appropriately.
    kuznet> etc.

    kuznet> No!

    kuznet> In fact, it is mathematical fact, that as soon as order is
    kuznet> broken once it is _impossible_ to restore it back. No
    kuznet> valid actions are invented to do this f.e. for TCP.

Agreed.

    kuznet> Though with lapb the situation is different: it cannot
    kuznet> lose frames, this changes the situation.

Unfortunatly, the netif_rx might still loose frames, and its concurrent
netif_rx() which re-orders the frames. Thus, we cannot take advantage
of reliable LAPB below netif_rx when packet loss and re-ordering occured
above netif_rx().

    kuznet> In any case, order must not be broken, if it is
    kuznet> essential. That's answer.

I see. Apparently, IRQ affinity seems the only simple and cheep
solution the re-ordering problem.

Henner


From owner-netdev@oss.sgi.com Sat Sep 16 14:52:22 2000
Received:  by oss.sgi.com id <S42412AbQIPVwC>;
	Sat, 16 Sep 2000 14:52:02 -0700
Received: from kogge.hanse.de ([192.76.134.17]:62737 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S42403AbQIPVvw>;
	Sat, 16 Sep 2000 14:51:52 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id XAA68655;
	Sat, 16 Sep 2000 23:55:49 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id XAA01092;
	Sat, 16 Sep 2000 23:39:45 +0200
Date:   Sat, 16 Sep 2000 23:39:45 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200009162139.XAA01092@baty.hanse.de>
To:     alan@lxorguk.ukuu.org.uk
CC:     davem@redhat.com, kuznet@ms2.inr.ac.ru,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
In-reply-to: <E13a3yj-0008E6-00@the-village.bc.nu> (message from Alan Cox on
	Fri, 15 Sep 2000 23:29:03 +0100 (BST))
Subject: Re: Q: sock output serialization
References:  <E13a3yj-0008E6-00@the-village.bc.nu>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Hi,

>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

    >> However, for drivers which support intelligent controllers
    >> (with lapb in firmware) this is not an option and the problem
    >> will persist.

    Alan> 'Smart hardware is broken' repeat .. ;) - but yes its an
    Alan> issue there. These cards could bypass netif_rx and call
    Alan> directly to the lapb top end though ?

What about a function to query the state of the backlog queue?

Something like

if(netif_would_drop(dev)){
        kfree_skb(skb);
	/*optionally,if supported by lapb implementation:*/
			set_lapb_rx_busy_condition();
	return;	
}
clear_lapb_rx_busy_condition(); /* if supported */
pass_frame_to_lapb(lapb,skb);

The key point is that we need to query the backlog queue and
discard the skb before lapb can acknowledge it. Simply discarding
it when backlog is known to be congested should be sufficient. It could
however improve performance if lapb did additionally flow control the peer.

With the current scheme, lapb first acknowleges reception of the frame
and after that, netif_rx() might still discard it -- which is evil.

Provided that netif_would_drop(dev) is reliable (a subsequent netif_rf will
reliably not drop the frame), this should make the netif_rx path reliable.

It seems that, on 2.4.0, something like

int netif_would_drop(dev)
{
	return (queue->input_pkt_queue.qlen > netdev_max_backlog)
	       || ( (queue->input_pkt_queue.qlen) && (queue->throttle) )
}

would fulfil those requirements.

Henner

From owner-netdev@oss.sgi.com Sat Sep 16 15:39:23 2000
Received:  by oss.sgi.com id <S42414AbQIPWjN>;
	Sat, 16 Sep 2000 15:39:13 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:26250 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42403AbQIPWiu>;
	Sat, 16 Sep 2000 15:38:50 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id SAA02749;
	Sat, 16 Sep 2000 18:38:49 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id SAA28897;
	Sat, 16 Sep 2000 18:38:49 -0400 (EDT)
Date:   Sat, 16 Sep 2000 18:38:49 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Henner Eisen <eis@baty.hanse.de>
cc:     alan@lxorguk.ukuu.org.uk, davem@redhat.com, kuznet@ms2.inr.ac.ru,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: Q: sock output serialization
In-Reply-To: <200009162139.XAA01092@baty.hanse.de>
Message-ID: <Pine.GSO.4.20.0009161805100.9880-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


Seems all the good network stuff gets discussed on l-k instead ;-<
(hint: some people are not subscribed to l-k)

On Sat, 16 Sep 2000, Henner Eisen wrote:

> 
> What about a function to query the state of the backlog queue?
> 
> Something like
> 
> if(netif_would_drop(dev)){
>         kfree_skb(skb);
> 	/*optionally,if supported by lapb implementation:*/
> 			set_lapb_rx_busy_condition();
> 	return;	
> }
> clear_lapb_rx_busy_condition(); /* if supported */
> pass_frame_to_lapb(lapb,skb);
> 
> The key point is that we need to query the backlog queue and
> discard the skb before lapb can acknowledge it. Simply discarding
> it when backlog is known to be congested should be sufficient. It could
> however improve performance if lapb did additionally flow control the peer.


This should be resolved by a patch i am about to submit based on the OLS
talk.
netif_rx() now returns a value which tells you the congestion levels when
you give it a packet (change from void netif_rx())

--- 
/*      return values:
 *      BLG_CNG_NONE    (no congestion)           
 *      BLG_CNG_LOW     (low congestion) 
 *      BLG_CNG_MOD     (moderate congestion)
 *      BLG_CNG_HIGH    (high congestion) 
 *      BLG_CNG_DROP    (packet was dropped)
 */      
---

> 
> With the current scheme, lapb first acknowleges reception of the frame
> and after that, netif_rx() might still discard it -- which is evil.
> 

This might screw things a bit. Can you defer to say first call
netif_rx() then acknowledge or is this hard-coded into the f/ware?


> Provided that netif_would_drop(dev) is reliable (a subsequent netif_rf will
> reliably not drop the frame), this should make the netif_rx path reliable.
> 
> It seems that, on 2.4.0, something like
> 
> int netif_would_drop(dev)
> {
> 	return (queue->input_pkt_queue.qlen > netdev_max_backlog)
> 	       || ( (queue->input_pkt_queue.qlen) && (queue->throttle) )
> }
> 
> would fulfil those requirements.

I think this would make it a little more complex than necessary; the queue
state might change right after you return from netif_would_drop() -- maybe
not, i am just hypothesizing. 
** You can still create the netif_would_drop() --it just sounds too
expensive to me since to be realy sure no packet of yours is dropped, you
have to make this call for every packet.

If you cant defer the acknowledgement until netif_rx() returns then what
we could do is instead: 

1) for devices that are registered with hardware flow control
==> you have to register as a CONFIG_NET_HW_FLOWCONTROL device.

a) to let them queue that last packet before they are shut-up, the
assumption is they respect the protocol and will 'back-off' after
that. 
b) return BLG_CNG_WOULD_DROP instead to the device and give it the
responsibility to free the skb or store it wherever it wants but not in
the backlog.

I personally prefer a). Reason: If we have done all the work so
far(context switch etc) and we know the device is well behaved(meaning it
is not going to send another packet without beiong told things are fine) 
then it is probably wiser to just let that packet get on the backlog
queue.

cheers,
jamal


From owner-netdev@oss.sgi.com Sat Sep 16 15:48:13 2000
Received:  by oss.sgi.com id <S42415AbQIPWrx>;
	Sat, 16 Sep 2000 15:47:53 -0700
Received: from lightning.swansea.uk.linux.org ([194.168.151.1]:18480 "EHLO
        the-village.bc.nu") by oss.sgi.com with ESMTP id <S42403AbQIPWrm>;
	Sat, 16 Sep 2000 15:47:42 -0700
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 13aQd5-0002Ej-00; Sat, 16 Sep 2000 23:40:15 +0100
Subject: Re: Q: sock output serialization
To:     hadi@cyberus.ca (jamal)
Date:   Sat, 16 Sep 2000 23:40:13 +0100 (BST)
Cc:     eis@baty.hanse.de (Henner Eisen), alan@lxorguk.ukuu.org.uk,
        davem@redhat.com, kuznet@ms2.inr.ac.ru,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
In-Reply-To: <Pine.GSO.4.20.0009161805100.9880-100000@shell.cyberus.ca> from "jamal" at Sep 16, 2000 06:38:49 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: <E13aQd5-0002Ej-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

> > With the current scheme, lapb first acknowleges reception of the frame
> > and after that, netif_rx() might still discard it -- which is evil.
> 
> This might screw things a bit. Can you defer to say first call
> netif_rx() then acknowledge or is this hard-coded into the f/ware?

I think its fixable to make it do the RR/RNR after bouncing it up the stack.

From owner-netdev@oss.sgi.com Sat Sep 16 16:55:13 2000
Received:  by oss.sgi.com id <S42416AbQIPXzD>;
	Sat, 16 Sep 2000 16:55:03 -0700
Received: from Cantor.suse.de ([194.112.123.193]:7688 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42403AbQIPXyj>;
	Sat, 16 Sep 2000 16:54:39 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 5C5841E241; Sun, 17 Sep 2000 01:54:37 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 22B7110A02C; Sun, 17 Sep 2000 01:54:37 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id EB9082F300; Sun, 17 Sep 2000 01:54:35 +0200 (MEST)
Date:   Sun, 17 Sep 2000 01:54:35 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Henner Eisen <eis@baty.hanse.de>
Cc:     alan@lxorguk.ukuu.org.uk, davem@redhat.com, kuznet@ms2.inr.ac.ru,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: Q: sock output serialization
Message-ID: <20000917015435.A712@gruyere.muc.suse.de>
References: <E13a3yj-0008E6-00@the-village.bc.nu> <200009162139.XAA01092@baty.hanse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200009162139.XAA01092@baty.hanse.de>; from eis@baty.hanse.de on Sat, Sep 16, 2000 at 11:39:45PM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sat, Sep 16, 2000 at 11:39:45PM +0200, Henner Eisen wrote:
> int netif_would_drop(dev)
> {
> 	return (queue->input_pkt_queue.qlen > netdev_max_backlog)
> 	       || ( (queue->input_pkt_queue.qlen) && (queue->throttle) )
> }
> 
> would fulfil those requirements.

It would just be racy. You test, get a not drop and then another different
interrupt would deliver another packet before you can and fill the queue.
Jamal's extended netif_rx probably makes more sense, because it can be 
atomic.


-Andi

From owner-netdev@oss.sgi.com Sun Sep 17 01:43:07 2000
Received:  by oss.sgi.com id <S42309AbQIQIm5>;
	Sun, 17 Sep 2000 01:42:57 -0700
Received: from kogge.hanse.de ([192.76.134.17]:60946 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S42297AbQIQImc>;
	Sun, 17 Sep 2000 01:42:32 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id KAA83834;
	Sun, 17 Sep 2000 10:47:06 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id JAA02552;
	Sun, 17 Sep 2000 09:02:10 +0200
Date:   Sun, 17 Sep 2000 09:02:10 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200009170702.JAA02552@baty.hanse.de>
To:     ak@suse.de
CC:     alan@lxorguk.ukuu.org.uk, davem@redhat.com, kuznet@ms2.inr.ac.ru,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
In-reply-to: <20000917015435.A712@gruyere.muc.suse.de> (ak@suse.de)
Subject: Re: Q: sock output serialization
References: <E13a3yj-0008E6-00@the-village.bc.nu> <200009162139.XAA01092@baty.hanse.de> <20000917015435.A712@gruyere.muc.suse.de>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

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

    Andi> It would just be racy. You test, get a not drop and then
    Andi> another different interrupt would deliver another packet
    Andi> before you can and fill the queue.  Jamal's extended
    Andi> netif_rx probably makes more sense, because it can be
    Andi> atomic.

I thought if it was executed from the same single interrupt handler
(and lapb also processed from that same interrupt handler) while
local irq are disables, this could not happen.
But for smart controllers, this does not hold, they would need to
interrupt the cpu first to query the state, and than again before
delivering the packet. And for dumb cards, doing the lapb processing
inside irq handler is not nice, anyway. Moving lapb processing above
netif_rx() would resolve this and all other problems.

Henner


From owner-netdev@oss.sgi.com Sun Sep 17 01:44:27 2000
Received:  by oss.sgi.com id <S42419AbQIQIoG>;
	Sun, 17 Sep 2000 01:44:06 -0700
Received: from kogge.hanse.de ([192.76.134.17]:62738 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S42297AbQIQInx>;
	Sun, 17 Sep 2000 01:43:53 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id KAA83844;
	Sun, 17 Sep 2000 10:48:27 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id KAA02693;
	Sun, 17 Sep 2000 10:32:51 +0200
Date:   Sun, 17 Sep 2000 10:32:51 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200009170832.KAA02693@baty.hanse.de>
To:     hadi@cyberus.ca
CC:     alan@lxorguk.ukuu.org.uk, davem@redhat.com, kuznet@ms2.inr.ac.ru,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
In-reply-to: <Pine.GSO.4.20.0009161805100.9880-100000@shell.cyberus.ca>
	(message from jamal on Sat, 16 Sep 2000 18:38:49 -0400 (EDT))
Subject: Re: Q: sock output serialization
References:  <Pine.GSO.4.20.0009161805100.9880-100000@shell.cyberus.ca>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi,

>>>>> "jamal" == jamal  <hadi@cyberus.ca> writes:

    >>  With the current scheme, lapb first acknowleges reception of
    >> the frame and after that, netif_rx() might still discard it --
    >> which is evil.
    >> 

    jamal> This might screw things a bit. Can you defer to say first
    jamal> call netif_rx() then acknowledge or is this hard-coded into
    jamal> the f/ware?

This depends on the firmware. I don´t know. The software lapb module
could be modified to honor a return vale appropriately. But software
lapb should be moved above netif for several other reasons anyway 
(although even there, honoring a return value for flow control
would make sense). Maybe it is a good idea to make the congestion
return values not netif specific, but making them part of a generic
"return semantics for delivering packets to upper layers".  

The driver maintainers will need to investigate this and take appropriate
actions depending on the firmware´s capabilities.

My personal use of the X.25 stack was using it in DTE-DTE mode over
isdn where I use the isdn-driver´s internal lapb (x75i) implementation.
Unfortunatly, the interface to the isdn lower layers does not allow to
return an rx_busy condition.

    >> Provided that netif_would_drop(dev) is reliable (a subsequent

    jamal> I think this would make it a little more complex than
    jamal> necessary; the queue state might change right after you

Yes, the scenario I had in mind (where it would have been reliable)
was a little short-sighted (see reply to Andi´s message).

    jamal> If you cant defer the acknowledgement until netif_rx()
    jamal> returns then what we could do is instead:

    jamal> 1) for devices that are registered with hardware flow
    jamal> control ==> you have to register as a
    jamal> CONFIG_NET_HW_FLOWCONTROL device.

    jamal> a) to let them queue that last packet before they are
    jamal> shut-up, the assumption is they respect the protocol and
    jamal> will 'back-off' after that.  
    jamal> b) return BLG_CNG_WOULD_DROP
    jamal> instead to the device and give it the responsibility to
    jamal> free the skb or store it wherever it wants but not in the
    jamal> backlog.

    jamal> I personally prefer a). Reason: If we have done all the
    jamal> work so far(context switch etc) and we know the device is
    jamal> well behaved(meaning it is not going to send another packet
    jamal> without beiong told things are fine) then it is probably
    jamal> wiser to just let that packet get on the backlog queue.

Yes, a) that would make life much simpler for driver writers (but more
difficult for you ;). If it is doable without adding overhead to the
general path, it would be nice to provide that semantics to HW_FLOWCONTROLed
devices.

However, even with a), after being HW-flow-controlled and setting rx_busy
condition, there could still arrive some more packets until the send window
is full. They either need to be discarded at once or queued somewhere else.
If we don´t want to discard them, you need to accept packets up
to the window size from a device after it has been HW flow conrolled.

Henner





From owner-netdev@oss.sgi.com Sun Sep 17 06:25:07 2000
Received:  by oss.sgi.com id <S42317AbQIQNY5>;
	Sun, 17 Sep 2000 06:24:57 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:40697 "EHLO cyberus.ca") convert rfc822-to-8bit
	by oss.sgi.com with ESMTP id <S42297AbQIQNYg>;
	Sun, 17 Sep 2000 06:24:36 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id JAA27782;
	Sun, 17 Sep 2000 09:24:31 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id JAA00349;
	Sun, 17 Sep 2000 09:24:29 -0400 (EDT)
Date:   Sun, 17 Sep 2000 09:24:29 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Henner Eisen <eis@baty.hanse.de>
cc:     alan@lxorguk.ukuu.org.uk, davem@redhat.com, kuznet@ms2.inr.ac.ru,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: Q: sock output serialization
In-Reply-To: <200009170832.KAA02693@baty.hanse.de>
Message-ID: <Pine.GSO.4.20.0009170916370.334-100000@shell.cyberus.ca>
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 Sun, 17 Sep 2000, Henner Eisen wrote:

> Yes, a) that would make life much simpler for driver writers (but more
> difficult for you ;). If it is doable without adding overhead to the
> general path, it would be nice to provide that semantics to HW_FLOWCONTROLed
> devices.
> 

There would be a minute overhead. But i guess let me release the patch
first then we can continue this part of the conversation. 

> However, even with a), after being HW-flow-controlled and setting rx_busy
> condition, there could still arrive some more packets until the send window
> is full. They either need to be discarded at once or queued somewhere else.
> If we don´t want to discard them, you need to accept packets up
> to the window size from a device after it has been HW flow conrolled.

Hmm.. More complexity ;->
Does X.25 mandate you accept all the window? Can you stop mid-window and
claim there is congestion? (maybe time to dust off some books).

cheers,
jamal



From owner-netdev@oss.sgi.com Sun Sep 17 13:56:09 2000
Received:  by oss.sgi.com id <S42201AbQIQU4A>;
	Sun, 17 Sep 2000 13:56:00 -0700
Received: from kogge.hanse.de ([192.76.134.17]:24069 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S42186AbQIQUzo>;
	Sun, 17 Sep 2000 13:55:44 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id XAA02366;
	Sun, 17 Sep 2000 23:00:02 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id SAA03980;
	Sun, 17 Sep 2000 18:20:57 +0200
Date:   Sun, 17 Sep 2000 18:20:57 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200009171620.SAA03980@baty.hanse.de>
To:     hadi@cyberus.ca
CC:     alan@lxorguk.ukuu.org.uk, davem@redhat.com, kuznet@ms2.inr.ac.ru,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
In-reply-to: <Pine.GSO.4.20.0009170916370.334-100000@shell.cyberus.ca>
	(message from jamal on Sun, 17 Sep 2000 09:24:29 -0400 (EDT))
Subject: Re: Q: sock output serialization
References:  <Pine.GSO.4.20.0009170916370.334-100000@shell.cyberus.ca>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "jamal" == jamal  <hadi@cyberus.ca> writes:

    jamal> Hmm.. More complexity ;-> Does X.25 mandate you accept all
    jamal> the window?

No. Just, if you do not accept a frame, you must not acknowledge it.
Once it has been acknowledged, you must not discard it.

    jamal> Can you stop mid-window and claim there is
    jamal> congestion? (maybe time to dust off some books).

Yes.

Just had a look at the X.25 specs again. As far as LAPB is concerned
(and that´s what we are speeking about), it is like this:
When your receiver is busy, you tell the other end about this by means
of a ReceiverNotReady primitive. However, it might take some time until
the peer receives it and reacts on this. In the extreme case, there
could still arrive up to the window size frames. It seems that the
receiver can do whatever it wants to do with frames received during the
busy condition: Either accept the frames (but delay acknowledgement until
the busy condition is cleared) or just discard them. The first one seems
to favor performance while the second favors simplicity.

I guess in Linux, we should usually choose simplicity. I think even
with the simpicity variant, we could be able to preserve performance
if we can flow control the peer earlier. E.g. when the return value of
your netif_rx indicates 'almost congested, but still able to accept frames',
we could already set the busy condition but continue to deliver the
frames arriving during our busy condition. But that´s performance tuning
and can be taken care of later (I´m even not sure wheter this tuning will
pay off).

Henner




From owner-netdev@oss.sgi.com Sun Sep 17 18:40:03 2000
Received:  by oss.sgi.com id <S42234AbQIRBjo>;
	Sun, 17 Sep 2000 18:39:44 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:50560 "EHLO cyberus.ca") convert rfc822-to-8bit
	by oss.sgi.com with ESMTP id <S42186AbQIRBjK>;
	Sun, 17 Sep 2000 18:39:10 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id VAA29588;
	Sun, 17 Sep 2000 21:38:40 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id VAA01042;
	Sun, 17 Sep 2000 21:38:39 -0400 (EDT)
Date:   Sun, 17 Sep 2000 21:38:38 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Henner Eisen <eis@baty.hanse.de>
cc:     alan@lxorguk.ukuu.org.uk, davem@redhat.com, kuznet@ms2.inr.ac.ru,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: Q: sock output serialization
In-Reply-To: <200009171620.SAA03980@baty.hanse.de>
Message-ID: <Pine.GSO.4.20.0009172129060.979-100000@shell.cyberus.ca>
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 Sun, 17 Sep 2000, Henner Eisen wrote:

> >>>>> "jamal" == jamal  <hadi@cyberus.ca> writes:
> No. Just, if you do not accept a frame, you must not acknowledge it.
> Once it has been acknowledged, you must not discard it.

Ok so no problem then 

> 
>     jamal> Can you stop mid-window and claim there is
>     jamal> congestion? (maybe time to dust off some books).
> 
> Yes.

Again, this makes life simpler. You dont have to accept the whole window.

> Just had a look at the X.25 specs again. As far as LAPB is concerned
> (and that´s what we are speeking about), it is like this:
> When your receiver is busy, you tell the other end about this by means
> of a ReceiverNotReady primitive. However, it might take some time until
> the peer receives it and reacts on this. 

Packets in flight?

> In the extreme case, there could still arrive up to the window size
> frames. 

Assuming this depends on path latency and not some bad programming

> It seems that the
> receiver can do whatever it wants to do with frames received during the
> busy condition: Either accept the frames (but delay acknowledgement until
> the busy condition is cleared) or just discard them. The first one seems
> to favor performance while the second favors simplicity.
> 
> I guess in Linux, we should usually choose simplicity. I think even
> with the simpicity variant, we could be able to preserve performance
> if we can flow control the peer earlier. E.g. when the return value of
> your netif_rx indicates 'almost congested, but still able to accept frames',
> we could already set the busy condition but continue to deliver the
> frames arriving during our busy condition. But that´s performance tuning
> and can be taken care of later (I´m even not sure wheter this tuning will
> pay off).
> 

This is doable. the 'almost congested, but still able to accept frames'
is a tunable parameter via proc.
Nobody is stopping you from maintaining your own little queue in the
driver to take the first option. The complexity is added to your driver as
opposed to the general system.

BTW, earlier i lied: there is a way to tell if your packet will be dropped
which is not very expensive:

	if (atomic_read(&netdev_dropping)
		/* packet will be dropped */

but even this is 99% accurate in SMP.

cheers,
jamal


From owner-netdev@oss.sgi.com Mon Sep 18 01:30:58 2000
Received:  by oss.sgi.com id <S42229AbQIRIal>;
	Mon, 18 Sep 2000 01:30:41 -0700
Received: from panic.ohr.gatech.edu ([130.207.47.194]:46087 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S42186AbQIRIaJ>;
	Mon, 18 Sep 2000 01:30:09 -0700
Received: from mandrakesoft.com (adsl-77-228-182.atl.bellsouth.net [216.77.228.182])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id EAA14680;
	Mon, 18 Sep 2000 04:29:22 -0400
Message-ID: <39C5D263.8DA31C03@mandrakesoft.com>
Date:   Mon, 18 Sep 2000 04:29:23 -0400
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
CC:     netdev@oss.sgi.com, "David S. Miller" <davem@redhat.com>,
        jes@linuxcare.com
Subject: PATCH 2.4.0.9.2: export ethtool interface
Content-Type: multipart/mixed;
 boundary="------------BF3A71278F4AD99F17D97FB7"
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.
--------------BF3A71278F4AD99F17D97FB7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This patch, against 2.4.0-test9-pre2, moves ethtool.h from the private
domain of the sparc ports into include/linux.  This publishes an
existing interface, and has been discussed before.  (search past lkml
subject headers for "media tool" and "ethtool")

This updated patch should take some of the past threads into account. 
The differences from the current sparc ethtool.h are:

* bitmask for advertising as well as supported media types
* interrupt mitigation hints max{tx,rx}pkt (Jes suggestion)
* four reserved u32 slots for future expansion
* assigned an ioctl: SIOCETHTOOL (0x8944)

Questions, comments, and feedback welcome.  If there are no objections,
I'll submit to DaveM for inclusion in 2.4.0-test9-whatever, after this
current round of discussion.

	Jeff
--------------BF3A71278F4AD99F17D97FB7
Content-Type: text/plain; charset=us-ascii;
 name="ethtool-2.4.0.9.2.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ethtool-2.4.0.9.2.patch"

diff -urN vanilla/linux-2.4.0-test9-pre2/include/linux/ethtool.h linux_2_3/include/linux/ethtool.h
--- vanilla/linux-2.4.0-test9-pre2/include/linux/ethtool.h	Wed Dec 31 19:00:00 1969
+++ linux_2_3/include/linux/ethtool.h	Sun Sep 17 17:29:10 2000
@@ -0,0 +1,96 @@
+/* $Id: ethtool.h,v 1.1.186.1 2000/09/16 20:13:14 jgarzik Exp $
+ * ethtool.h: Defines for Linux ethtool.
+ *
+ * Copyright (C) 1998 David S. Miller (davem@redhat.com)
+ */
+
+#ifndef _LINUX_ETHTOOL_H
+#define _LINUX_ETHTOOL_H
+
+
+/* This should work for both 32 and 64 bit userland. */
+struct ethtool_cmd {
+	u32	cmd;
+	u32	supported;	/* Features this interface supports */
+	u32	advertising;	/* Features this interface advertises */
+	u16	speed;		/* The forced speed, 10Mb, 100Mb, gigabit */
+	u8	duplex;		/* Duplex, half or full */
+	u8	port;		/* Which connector port */
+	u8	phy_address;
+	u8	transceiver;	/* Which tranceiver to use */
+	u8	autoneg;	/* Enable or disable autonegotiation */
+	u32	maxtxpkt;	/* Tx pkts before generating tx int */
+	u32	maxrxpkt;	/* Rx pkts before generating rx int */
+	u32	reserved[4];
+};
+
+
+/* CMDs currently supported */
+#define ETHTOOL_GSET		0x00000001 /* Get settings, non-privileged. */
+#define ETHTOOL_SSET		0x00000002 /* Set settings, privileged. */
+
+/* compatibility with older code */
+#define SPARC_ETH_GSET		ETHTOOL_GSET
+#define SPARC_ETH_SSET		ETHTOOL_SSET
+
+/* Indicates what features are supported by the interface. */
+#define SUPPORTED_10baseT_Half		(1 << 0)
+#define SUPPORTED_10baseT_Full		(1 << 1)
+#define SUPPORTED_100baseT_Half		(1 << 2)
+#define SUPPORTED_100baseT_Full		(1 << 3)
+#define SUPPORTED_1000baseT_Half	(1 << 4)
+#define SUPPORTED_1000baseT_Full	(1 << 5)
+#define SUPPORTED_Autoneg		(1 << 6)
+#define SUPPORTED_TP			(1 << 7)
+#define SUPPORTED_AUI			(1 << 8)
+#define SUPPORTED_MII			(1 << 9)
+#define SUPPORTED_FIBRE			(1 << 10)
+
+/* Indicates what features are advertised by the interface. */
+#define ADVERTISED_10baseT_Half		(1 << 0)
+#define ADVERTISED_10baseT_Full		(1 << 1)
+#define ADVERTISED_100baseT_Half	(1 << 2)
+#define ADVERTISED_100baseT_Full	(1 << 3)
+#define ADVERTISED_1000baseT_Half	(1 << 4)
+#define ADVERTISED_1000baseT_Full	(1 << 5)
+#define ADVERTISED_Autoneg		(1 << 6)
+#define ADVERTISED_TP			(1 << 7)
+#define ADVERTISED_AUI			(1 << 8)
+#define ADVERTISED_MII			(1 << 9)
+#define ADVERTISED_FIBRE		(1 << 10)
+
+/* The following are all involved in forcing a particular link
+ * mode for the device for setting things.  When getting the
+ * devices settings, these indicate the current mode and whether
+ * it was foced up into this mode or autonegotiated.
+ */
+
+/* The forced speed, 10Mb, 100Mb, gigabit. */
+#define SPEED_10		10
+#define SPEED_100		100
+#define SPEED_1000		1000
+
+/* Duplex, half or full. */
+#define DUPLEX_HALF		0x00
+#define DUPLEX_FULL		0x01
+
+/* Which connector port. */
+#define PORT_TP			0x00
+#define PORT_AUI		0x01
+#define PORT_MII		0x02
+#define PORT_FIBRE		0x03
+
+/* Which tranceiver to use. */
+#define XCVR_INTERNAL		0x00
+#define XCVR_EXTERNAL		0x01
+#define XCVR_DUMMY1		0x02
+#define XCVR_DUMMY2		0x03
+#define XCVR_DUMMY3		0x04
+
+/* Enable or disable autonegotiation.  If this is set to enable,
+ * the forced link modes above are completely ignored.
+ */
+#define AUTONEG_DISABLE		0x00
+#define AUTONEG_ENABLE		0x01
+
+#endif /* _LINUX_ETHTOOL_H */
diff -urN vanilla/linux-2.4.0-test9-pre2/drivers/net/sunhme.c linux_2_3/drivers/net/sunhme.c
--- vanilla/linux-2.4.0-test9-pre2/drivers/net/sunhme.c	Thu Sep  7 11:32:00 2000
+++ linux_2_3/drivers/net/sunhme.c	Sun Sep 17 17:29:03 2000
@@ -24,6 +24,7 @@
 #include <linux/string.h>
 #include <linux/delay.h>
 #include <linux/init.h>
+#include <linux/ethtool.h>
 #include <asm/system.h>
 #include <asm/bitops.h>
 #include <asm/io.h>
@@ -41,7 +42,6 @@
 #ifndef __sparc_v9__
 #include <asm/io-unit.h>
 #endif
-#include <asm/ethtool.h>
 #include <asm/uaccess.h>
 
 #include <linux/netdevice.h>
diff -urN vanilla/linux-2.4.0-test9-pre2/include/asm-sparc/ethtool.h linux_2_3/include/asm-sparc/ethtool.h
--- vanilla/linux-2.4.0-test9-pre2/include/asm-sparc/ethtool.h	Tue Feb  1 02:37:19 2000
+++ linux_2_3/include/asm-sparc/ethtool.h	Wed Dec 31 19:00:00 1969
@@ -1,79 +0,0 @@
-/* $Id: ethtool.h,v 1.2 2000/01/31 04:59:17 davem Exp $
- * ethtool.h: Defines for SparcLinux ethtool.
- *
- * Copyright (C) 1998 David S. Miller (davem@redhat.com)
- */
-
-#ifndef _SPARC_ETHTOOL_H
-#define _SPARC_ETHTOOL_H
-
-/* We do things like this so it does not matter what kernel
- * headers you have on your system etc.
- */
-#undef SIOCETHTOOL
-#define SIOCETHTOOL	(SIOCDEVPRIVATE + 0x0f)
-
-/* This should work for both 32 and 64 bit userland. */
-struct ethtool_cmd {
-	u32	cmd;
-	u32	supported;
-	u16	speed;
-	u8	duplex;
-	u8	port;
-	u8	phy_address;
-	u8	transceiver;
-	u8	autoneg;
-};
-
-/* CMDs currently supported */
-#define SPARC_ETH_GSET		0x00000001	/* Get settings, non-privileged. */
-#define SPARC_ETH_SSET		0x00000002	/* Set settings, privileged. */
-
-/* Indicates what features are supported by the interface. */
-#define SUPPORTED_10baseT_Half		0x00000001
-#define SUPPORTED_10baseT_Full		0x00000002
-#define SUPPORTED_100baseT_Half		0x00000004
-#define SUPPORTED_100baseT_Full		0x00000008
-#define SUPPORTED_1000baseT_Half	0x00000010
-#define SUPPORTED_1000baseT_Full	0x00000020
-#define SUPPORTED_Autoneg		0x00000040
-#define SUPPORTED_TP			0x00000080
-#define SUPPORTED_AUI			0x00000100
-#define SUPPORTED_MII			0x00000200
-#define SUPPORTED_FIBRE			0x00000400
-
-/* The following are all involved in forcing a particular link
- * mode for the device for setting things.  When getting the
- * devices settings, these indicate the current mode and whether
- * it was foced up into this mode or autonegotiated.
- */
-
-/* The forced speec, 10Mb, 100Mb, gigabit. */
-#define SPEED_10		10
-#define SPEED_100		100
-#define SPEED_1000		1000
-
-/* Duplex, half or full. */
-#define DUPLEX_HALF		0x00
-#define DUPLEX_FULL		0x01
-
-/* Which connector port. */
-#define PORT_TP			0x00
-#define PORT_AUI		0x01
-#define PORT_MII		0x02
-#define PORT_FIBRE		0x03
-
-/* Which tranceiver to use. */
-#define XCVR_INTERNAL		0x00
-#define XCVR_EXTERNAL		0x01
-#define XCVR_DUMMY1		0x02
-#define XCVR_DUMMY2		0x03
-#define XCVR_DUMMY3		0x04
-
-/* Enable or disable autonegotiation.  If this is set to enable,
- * the forced link modes above are completely ignored.
- */
-#define AUTONEG_DISABLE		0x00
-#define AUTONEG_ENABLE		0x01
-
-#endif /* _SPARC_ETHTOOL_H */
diff -urN vanilla/linux-2.4.0-test9-pre2/include/asm-sparc64/ethtool.h linux_2_3/include/asm-sparc64/ethtool.h
--- vanilla/linux-2.4.0-test9-pre2/include/asm-sparc64/ethtool.h	Tue Feb  1 02:37:19 2000
+++ linux_2_3/include/asm-sparc64/ethtool.h	Wed Dec 31 19:00:00 1969
@@ -1,79 +0,0 @@
-/* $Id: ethtool.h,v 1.2 2000/01/31 04:59:19 davem Exp $
- * ethtool.h: Defines for SparcLinux ethtool.
- *
- * Copyright (C) 1998 David S. Miller (davem@redhat.com)
- */
-
-#ifndef _SPARC64_ETHTOOL_H
-#define _SPARC64_ETHTOOL_H
-
-/* We do things like this so it does not matter what kernel
- * headers you have on your system etc.
- */
-#undef SIOCETHTOOL
-#define SIOCETHTOOL	(SIOCDEVPRIVATE + 0x0f)
-
-/* This should work for both 32 and 64 bit userland. */
-struct ethtool_cmd {
-	u32	cmd;
-	u32	supported;
-	u16	speed;
-	u8	duplex;
-	u8	port;
-	u8	phy_address;
-	u8	transceiver;
-	u8	autoneg;
-};
-
-/* CMDs currently supported */
-#define SPARC_ETH_GSET		0x00000001	/* Get settings, non-privileged. */
-#define SPARC_ETH_SSET		0x00000002	/* Set settings, privileged. */
-
-/* Indicates what features are supported by the interface. */
-#define SUPPORTED_10baseT_Half		0x00000001
-#define SUPPORTED_10baseT_Full		0x00000002
-#define SUPPORTED_100baseT_Half		0x00000004
-#define SUPPORTED_100baseT_Full		0x00000008
-#define SUPPORTED_1000baseT_Half	0x00000010
-#define SUPPORTED_1000baseT_Full	0x00000020
-#define SUPPORTED_Autoneg		0x00000040
-#define SUPPORTED_TP			0x00000080
-#define SUPPORTED_AUI			0x00000100
-#define SUPPORTED_MII			0x00000200
-#define SUPPORTED_FIBRE			0x00000400
-
-/* The following are all involved in forcing a particular link
- * mode for the device for setting things.  When getting the
- * devices settings, these indicate the current mode and whether
- * it was foced up into this mode or autonegotiated.
- */
-
-/* The forced speec, 10Mb, 100Mb, gigabit. */
-#define SPEED_10		10
-#define SPEED_100		100
-#define SPEED_1000		1000
-
-/* Duplex, half or full. */
-#define DUPLEX_HALF		0x00
-#define DUPLEX_FULL		0x01
-
-/* Which connector port. */
-#define PORT_TP			0x00
-#define PORT_AUI		0x01
-#define PORT_MII		0x02
-#define PORT_FIBRE		0x03
-
-/* Which tranceiver to use. */
-#define XCVR_INTERNAL		0x00
-#define XCVR_EXTERNAL		0x01
-#define XCVR_DUMMY1		0x02
-#define XCVR_DUMMY2		0x03
-#define XCVR_DUMMY3		0x04
-
-/* Enable or disable autonegotiation.  If this is set to enable,
- * the forced link modes above are completely ignored.
- */
-#define AUTONEG_DISABLE		0x00
-#define AUTONEG_ENABLE		0x01
-
-#endif /* _SPARC64_ETHTOOL_H */
diff -urN vanilla/linux-2.4.0-test9-pre2/include/linux/sockios.h linux_2_3/include/linux/sockios.h
--- vanilla/linux-2.4.0-test9-pre2/include/linux/sockios.h	Sat Jan 22 14:54:57 2000
+++ linux_2_3/include/linux/sockios.h	Sun Sep 17 17:29:10 2000
@@ -71,7 +71,7 @@
 
 #define SIOCGIFTXQLEN	0x8942		/* Get the tx queue length	*/
 #define SIOCSIFTXQLEN	0x8943		/* Set the tx queue length 	*/
-
+#define SIOCETHTOOL	0x8944		/* Ethtool interface		*/
 
 /* ARP cache control calls. */
 		    /*  0x8950 - 0x8952  * obsolete calls, don't re-use */

--------------BF3A71278F4AD99F17D97FB7--


From owner-netdev@oss.sgi.com Mon Sep 18 04:48:49 2000
Received:  by oss.sgi.com id <S42243AbQIRLs3>;
	Mon, 18 Sep 2000 04:48:29 -0700
Received: from runyon.cygnus.com ([205.180.230.5]:64241 "EHLO cygnus.com")
	by oss.sgi.com with ESMTP id <S42186AbQIRLrz>;
	Mon, 18 Sep 2000 04:47:55 -0700
Received: from passion.cygnus.co.uk (passion.cygnus.co.uk [194.130.39.73])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id EAA17164;
	Mon, 18 Sep 2000 04:47:11 -0700 (PDT)
Received: from passion.cygnus.co.uk (dwmw2@localhost)
	by passion.cygnus.co.uk (8.11.0/8.9.3) with ESMTP id e8IBkwV29471;
	Mon, 18 Sep 2000 12:46:58 +0100
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
From:   David Woodhouse <dwmw2@infradead.org>
X-Accept-Language: en_GB
In-Reply-To: <E13aQd5-0002Ej-00@the-village.bc.nu> 
References: <E13aQd5-0002Ej-00@the-village.bc.nu> 
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc:     hadi@cyberus.ca (jamal), eis@baty.hanse.de (Henner Eisen),
        davem@redhat.com, kuznet@ms2.inr.ac.ru,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: Q: sock output serialization 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Mon, 18 Sep 2000 12:46:58 +0100
Message-ID: <29470.969277618@passion.cygnus.co.uk>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


alan@lxorguk.ukuu.org.uk said:
>  I think its fixable to make it do the RR/RNR after bouncing it up the
> stack. -

ARCnet does ACK in hardware. Packets don't hit the wire until the 
destination has indicated that it's got a buffer available.

You really want to be able to reserve space on the queue before telling the
chip to accept another incoming packet - not just realise afterwards that 
you've screwed up.

Strictly speaking, this fact is irrelevant to the case in question, but if 
we're modifying the generic code for LAPB, we might as well think about other 
protocols which require similar treatment.

--
dwmw2



From owner-netdev@oss.sgi.com Mon Sep 18 11:25:01 2000
Received:  by oss.sgi.com id <S42249AbQIRSYm>;
	Mon, 18 Sep 2000 11:24:42 -0700
Received: from e1.ny.us.ibm.com ([32.97.182.101]:14814 "EHLO e1.ny.us.ibm.com")
	by oss.sgi.com with ESMTP id <S42253AbQIRSYK>;
	Mon, 18 Sep 2000 11:24:10 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA203600
	for <netdev@oss.sgi.com>; Mon, 18 Sep 2000 14:23:21 -0400
From:   ychoi@us.ibm.com
Received: from d01ml097.pok.ibm.com (d01ml097.pok.ibm.com [9.117.250.85])
	by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.93) with ESMTP id OAA43266
	for <netdev@oss.sgi.com>; Mon, 18 Sep 2000 14:23:37 -0400
X-Priority: 3 (Normal)
Importance: Normal
Subject: ping source code
To:     netdev@oss.sgi.com
Date:   Mon, 18 Sep 2000 14:23:36 -0400
Message-ID: <OFA0B67E2D.F2144B01-ON8525695E.0064F377@pok.ibm.com>
X-MIMETrack: Serialize by Router on D01ML097/01/M/IBM(Release 5.0.4a |July 29, 2000) at
 09/18/2000 02:23:38 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

Hello! I got your address from the MAINTAINERS list. I am looking for the
ping source code with -I (capitol I) option where I can specify a device
name (not an interface address). On Redhat 6.2, I ran "man ping" and found
out the option is available. I need to use the coding in one of my program.
I will appreciate if you return to me.


Yoonkee Choi
   AT&T Global Network Services
   (847)407-4166
   Internet address: YCHOI@US.IBM.COM


From owner-netdev@oss.sgi.com Mon Sep 18 12:21:01 2000
Received:  by oss.sgi.com id <S42259AbQIRTUw>;
	Mon, 18 Sep 2000 12:20:52 -0700
Received: from mail.zmailer.org ([194.252.70.162]:46608 "EHLO zmailer.org")
	by oss.sgi.com with ESMTP id <S42253AbQIRTUl>;
	Mon, 18 Sep 2000 12:20:41 -0700
Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@zmailer.org))
	by mail.zmailer.org id <S378568AbQIRTU0>;
	Mon, 18 Sep 2000 22:20:26 +0300
Date:	Mon, 18 Sep 2000 22:20:26 +0300
From:	Matti Aarnio <matti.aarnio@zmailer.org>
To:	ychoi@us.ibm.com
Cc:	netdev@oss.sgi.com
Subject: Re: ping source code
Message-ID: <20000918222026.A11669@mea-ext.zmailer.org>
References: <OFA0B67E2D.F2144B01-ON8525695E.0064F377@pok.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OFA0B67E2D.F2144B01-ON8525695E.0064F377@pok.ibm.com>; from ychoi@us.ibm.com on Mon, Sep 18, 2000 at 02:23:36PM -0400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, Sep 18, 2000 at 02:23:36PM -0400, ychoi@us.ibm.com wrote:
> Hello! I got your address from the MAINTAINERS list. I am looking for the
> ping source code with -I (capitol I) option where I can specify a device
> name (not an interface address). On Redhat 6.2, I ran "man ping" and found
> out the option is available. I need to use the coding in one of my program.
> I will appreciate if you return to me.

$ rpm -qf /bin/ping 
iputils-20000121-2

   Ok, so you should look for  iputils-*.src.rpm   package for the source.

   Do you have any idea of how to open *.src.rpm files ?

> Yoonkee Choi
>    AT&T Global Network Services
>    (847)407-4166
>    Internet address: YCHOI@US.IBM.COM

/Matti Aarnio <matti.aarnio@zmailer.org>

From owner-netdev@oss.sgi.com Mon Sep 18 18:32:03 2000
Received:  by oss.sgi.com id <S42283AbQISBby>;
	Mon, 18 Sep 2000 18:31:54 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:28086 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42278AbQISBbb>;
	Mon, 18 Sep 2000 18:31:31 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id VAA29278;
	Mon, 18 Sep 2000 21:31:17 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id VAA03647;
	Mon, 18 Sep 2000 21:31:17 -0400 (EDT)
Date:   Mon, 18 Sep 2000 21:31:17 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     davem@redhat.com, kuznet@ms2.inr.ac.ru
cc:     Robert.Olsson@data.slu.se, linux-kernel@vger.kernel.org,
        netdev@oss.sgi.com, becker@scyld.com, eis@baty.hanse.de
Subject: [PATCH/RFC] (long) network interface changes
Message-ID: <Pine.GSO.4.20.0009182121310.3641-200000@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-969327077=:3641"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---559023410-851401618-969327077=:3641
Content-Type: TEXT/PLAIN; charset=US-ASCII



I apologize for the over 10K email.. consider this documentation ;->
This is cross-posted to l-k; i would prefer the discussions on netdev
or cc netdev (i am not subscribed to l-k)

This is a port against 2.4.0-test8 based on the OLS presentation i made 
"Fast Forwarding the Bird" available at:
http://robur.slu.se/Linux/net-development/jamal/FF-html/

There are lotsa improvements since OLS in a collaboration involving 
Robert Olsson and myself. 

Current snapshot is available via ftp from:
ftp://robur.slu.se:/pub/Linux/net-development/FF-bird-current.tgz
This includes a patched tulip driver; tested only on a DEC21143-based
4-port cards.

This RFC at:
ftp://robur.slu.se:/pub/Linux/net-development/README-FF

To make things interesting robur.slu.se is currently running these patches.

Acknowledgements
-----------------

1) Alexey Kuznetsov : Without his FF and FC these thoughts might never have
been born. Alexey is still involved whenever time permits.
2) Robert Olsson : Many insights and current partner-in-crime
3) Donald Becker : Well thought network driver design.

-----------------------------
Test updates September/2000:
-----------------------------

Robert Olson and I decided after the OLS that we were going to try to
hit the 100Mbps(148.8Kpps) routing peak by year end. I am afraid the
bar has been raised. Robert is already hitting with 2.4.0-test7 ~148Kpps
with a ASUS CUBX motherboard carrying PIII 700 MHZ coppermine with 
about 65% CPU utilization.
With a single PII based Dell machine i was able to get a consistent value of
110Kpps.

So the new goal is to go to about 500Kpps ;-> (maybe not by year end, but
surely by that next random Linux hacker conference)

A sample modified tulip driver (hacked by Alexey for 2.2 and mod'ed by Robert
and myself over a period of time) is supplied as an example on how to use the
feedback values.


General blurb
-------------

To begin, i have to say that forwarding 100Mbps of 64byte packets is _not_
a problem at all in Linux; Alexey's Fast Forwarding does a fine job.

FF, like in routers is _not_ subjected to Firewalling (eg CISCO Fast routing).
So the challenge was to try and do it without FF turned on so we could do 
firewalling.

** Very important to note:
Although the tests and improvements were for packet forwarding, the technique
used applies for servers under a heavy load. System congestion is moved down
to the hardware therefore alleviating the system overload. 
I believe we could have done better with the mindcraft tests with these 
changes in 2.2 (and HW FC turned on). 
[Fact is, HW FC was there but i suppose no-one knew you could
use Alexey's hacked version of the Tulip ;->]

The changes proposed below are transparent to drivers that dont use them. 
It is however highly encouraged they take advantage of the supplied 
interface. This does not break anything in 2.4. It is a clean patch.

- This is a first cut, hopefully discussions will ensue and maybe a 
revision of the patch. In particular of interest are the recent weird
requirements by the X.25 code.
Refer to thread on l-k "Re: Q: sock output serialization"
Henner, hoping to hear from you.

- I intend on submitting this patch for inclusion in 2.4 since it is 
non-intrusive. I suspect there will be about one more revision.

*** Proposed changes:

Change 1) 
---------

netif_rx() now returns a value to the driver (change from void).

The queue is divided into 4 configurable threshold regions:
*no congestion zone
*low congestion zone
*moderate congestion
*A high congestion zone.
*A drop zone where packets are dropped.
(the configuration interface is via /proc/sys/net/core/)

A positive value (different for each of the regions) implies that the packet 
was successfully queued whereas a negative value implies it was dropped.

The default congestion threshold values are based on engineering 
experimentation and not on theoretical scientific proofs. There are 
probably better ways of drawing up the associated thresholds.

I would like to add that the HW FC feature is _a neccessary requirement_
to complement this. Maybe i should say this complements HW FC.
If a driver keeps sending packets up to netif_rx() even when its been given 
feedback to stop, HW FC kicks in and the device is shut up; "sent to its room" 
so to speak. So the HW FC is considered the "when all else fails" rule.
A separate document will describe how to use HW FC for driver authors.
I think it should be a *mandantory* interface to drivers.

The netif_rx() feedback helps the driver get 2 insights:
i) understand the fate of the packets it sent up the stack. No point
in continuing to blast packets to the stack when they are being dropped.
(which happens today)
ii) smartly gauge the congestion level on the stack and adjust the
rate at which packets are being sent to the stack to reduce overall
system load. A scheme which moves the congestion away from the system and
onto the driver is considered a bonus. The tulip does this in two ways
selectable at compile: 1) Kill the rx thread or 2) kill the rx_interupt.
Both which work extremely well. 
[The sample tulip driver can be made to use 2) by undefining D_INT in
tulip.h ]

The driver uses the feedback information to intelligently adjust its 
sending rate.  (i.e reduce or increase calls to netif_rx() or send a 
congestion-experienced frame to its peer eg in X.25). 
In the sample tulip driver, dynamic mitigation based on congestion feedback 
is used. Under low congestion, the mitigation parameters are turned off 
(default behavior as is today); under heavy congestion we dynamically move 
up to 16 packet times. It is not mandatory to use this scheme; however, 
it serves as a good example. A word of caution: This scheme is still being
experimented on; we feel we could do better. Look at the code.

change 2) 
---------

The backlog queue is now getting sampled.
This helps in detecting incipient congestion by the top layer. 
Essentially, the sampler is a low-pass filter which weeds out 
"congestion detected" wolf-cries due to sudden short bursts which
fill the backlog. 

I have experimented with two schemes: one which samples the queue via 
a timer and one which does it per-packet and found that the per-packet
sampler gave better results (more samples, Shannon's theorem applies).
It didnt matter whether HZ was 100 or 1024 during the tests.
The measure of "better" was throughput.

change 3) 
---------

Introduce a scheme which does occasionaly send a "random-lie"
when around moderate to high congestions; 
The motivation for this is to improve unfairness issues of many devices
sharing the same backlog queue.
e.g if eth0 is blasting 70Kpps to the backlog queue and eth1 is merely 
sending 10pps, then under the current system setup, eth0 will pretty
much fill up the backlog (every time it gets drained) and have a
very small opportunities to queue for eth1. Imagine scaling this to over 
10 interfaces with eth0 blasting at that rate.

Solution i have devised:
- Randomly lie in the feedback to the driver when under moderate to high
congestion levels (tell device there is a higher congestion than really is).
Theory is that "the harder they come, the harder they fall". It is more
than likely that eth0s packets from the above example will be hit than 
say eth1 by the randomness (simply because there is more of them to take 
target shots at)

My testing with the included scheme (#ifdef RAND_LIE) indicates that fairness 
infact goes up; however, the overall throughput when only one interface
is utilizing the system goes down under heavy to moderate congestion.
I am including it here as a way to highlight the problem. I think there could
be better ways to do this.
Code is included and can be turned on by defining RAND_LIE in dev.c

change 4) 
---------

After a brief talk with Alexey and Robert at the OLS, i am withdrawing this 
change proposal.
Currently after netdev_dropping is raised, all incoming packets to the
backlog are dropped even if there was only a single packet on the queue. 
I had proposed removing that check. In a world with good driver-zens 
(system-zens?) where every driver backs off once system congestion is detected,
the change would make sense. It is, however, unfair to good citizens to backoff
while the bad guys are filling the backlog which is what would happen if the
change is made.


cheers,
jamal

---559023410-851401618-969327077=:3641
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=FF-patch-test8
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.20.0009182131170.3641@shell.cyberus.ca>
Content-Description: 
Content-Disposition: attachment; filename=FF-patch-test8

LS0tIGxpbnV4L25ldC9jb3JlL2Rldi5jLm9yaWcJVGh1IFNlcCAgNyAxMToz
MjowMSAyMDAwDQorKysgbGludXgvbmV0L2NvcmUvZGV2LmMJVHVlIFNlcCAx
MiAyMDowMjoyMCAyMDAwDQpAQCAtOTcsNiArOTcsOSBAQA0KIGV4dGVybiBp
bnQgcGxpcF9pbml0KHZvaWQpOw0KICNlbmRpZg0KIA0KKy8qDQorI2RlZmlu
ZSBSQU5EX0xJRSAxDQorKi8NCiBORVRfUFJPRklMRV9ERUZJTkUoZGV2X3F1
ZXVlX3htaXQpDQogTkVUX1BST0ZJTEVfREVGSU5FKHNvZnRuZXRfcHJvY2Vz
cykNCiANCkBAIC0xMzMsNiArMTM2LDExIEBADQogc3RhdGljIHN0cnVjdCBw
YWNrZXRfdHlwZSAqcHR5cGVfYmFzZVsxNl07CQkvKiAxNiB3YXkgaGFzaGVk
IGxpc3QgKi8NCiBzdGF0aWMgc3RydWN0IHBhY2tldF90eXBlICpwdHlwZV9h
bGwgPSBOVUxMOwkJLyogVGFwcyAqLw0KIA0KKyNpZmRlZiBvZmZsaW5lX3Nh
bXBsZQ0KK3N0YXRpYyB2b2lkIHNhbXBsZV9xdWV1ZSh1bnNpZ25lZCBsb25n
IGR1bW15KTsNCitzdGF0aWMgc3RydWN0IHRpbWVyX2xpc3Qgc2FtcF90aW1l
ciA9IHsgeyBOVUxMLCBOVUxMIH0sIDAsIDAsICZzYW1wbGVfcXVldWUgfTsN
CisjZW5kaWYNCisNCiAvKg0KICAqCU91ciBub3RpZmllciBsaXN0DQogICov
DQpAQCAtOTUxLDEyICs5NTksMjUgQEANCiAgID09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09Ki8NCiANCiBpbnQgbmV0ZGV2X21heF9iYWNrbG9nID0gMzAw
Ow0KKy8qIHRoZXNlIG51bWJlcnMgYXJlIHNlbGVjdGVkIGJhc2VkIG9uIGlu
dHVpdGlvbiBhbmQgc29tZQ0KK2V4cGVyaW1lbnRhdGlvbSwgaWYgeW91IGhh
dmUgbW9yZSBzY2llbnRpZmljIHdheSBvZiBkb2luZyB0aGlzDQorcGxlYXNl
IGdvIGFoZWFkIGFuZCBmaXggdGhpbmdzDQorKi8NCitpbnQgbm9fY29uZ190
aHJlc2g9MTA7DQoraW50IG5vX2Nvbmc9MjA7DQoraW50IGxvX2Nvbmc9MTAw
Ow0KK2ludCBtb2RfY29uZz0yOTA7DQorDQorDQogDQogc3RydWN0IG5ldGlm
X3J4X3N0YXRzIG5ldGRldl9yeF9zdGF0W05SX0NQVVNdOw0KIA0KIA0KICNp
ZmRlZiBDT05GSUdfTkVUX0hXX0ZMT1dDT05UUk9MDQorLyoNCiBzdGF0aWMg
YXRvbWljX3QgbmV0ZGV2X2Ryb3BwaW5nID0gQVRPTUlDX0lOSVQoMCk7DQor
Ki8NCithdG9taWNfdCBuZXRkZXZfZHJvcHBpbmcgPSBBVE9NSUNfSU5JVCgw
KTsNCiBzdGF0aWMgdW5zaWduZWQgbG9uZyBuZXRkZXZfZmNfbWFzayA9IDE7
DQogdW5zaWduZWQgbG9uZyBuZXRkZXZfZmNfeG9mZiA9IDA7DQogc3Bpbmxv
Y2tfdCBuZXRkZXZfZmNfbG9jayA9IFNQSU5fTE9DS19VTkxPQ0tFRDsNCkBA
IC0xMDE0LDYgKzEwMzUsNTYgQEANCiB9DQogI2VuZGlmDQogDQorc3RhdGlj
IHZvaWQgZ2V0X3NhbXBsZV9zdGF0cyhpbnQgY3B1KQ0KK3sNCisjaWZkZWYg
UkFORF9MSUUNCisJdW5zaWduZWQgbG9uZyByZDsNCisJaW50IHJxOw0KKyNl
bmRpZg0KKwlpbnQgYmxvZz1zb2Z0bmV0X2RhdGFbY3B1XS5pbnB1dF9wa3Rf
cXVldWUucWxlbjsNCisJaW50IGF2Z19ibG9nPXNvZnRuZXRfZGF0YVtjcHVd
LmF2Z19ibG9nOw0KKw0KKwlhdmdfYmxvZz0oYXZnX2Jsb2cgPj4gMSkrIChi
bG9nPj4xKTsNCisNCisJaWYgKGF2Z19ibG9nID4gbW9kX2NvbmcpIHsNCisv
KiAgYWJvdmUgbW9kZXJhdGUgY29uZ2VzdGlvbiBsZXZlbHMgKi8NCisJCXNv
ZnRuZXRfZGF0YVtjcHVdLmNuZ19sZXZlbD0gQkxHX0NOR19ISUdIOw0KKyNp
ZmRlZiBSQU5EX0xJRQ0KKwkJcmQ9bmV0X3JhbmRvbSgpOw0KKwkJcnE9cmQl
IG5ldGRldl9tYXhfYmFja2xvZzsNCisJCWlmIChycSA8IGF2Z19ibG9nKSAv
KiB1bmx1Y2t5IGJhc3RhcmQgKi8NCisJCQlzb2Z0bmV0X2RhdGFbY3B1XS5j
bmdfbGV2ZWw9QkxHX0NOR19EUk9QOw0KKyNlbmRpZg0KKwl9IGVsc2UgaWYg
KGF2Z19ibG9nID4gbG9fY29uZykgew0KKwkJc29mdG5ldF9kYXRhW2NwdV0u
Y25nX2xldmVsPSBCTEdfQ05HX01PRDsNCisjaWZkZWYgUkFORF9MSUUNCisJ
CXJkPW5ldF9yYW5kb20oKTsNCisJCXJxPXJkJSBuZXRkZXZfbWF4X2JhY2ts
b2c7DQorCQkJaWYgKHJxIDwgYXZnX2Jsb2cpIC8qIHVubHVja3kgYmFzdGFy
ZCAqLw0KKwkJCQlzb2Z0bmV0X2RhdGFbY3B1XS5jbmdfbGV2ZWw9QkxHX0NO
R19ISUdIOw0KKyNlbmRpZg0KKwl9IGVsc2UgaWYgKGF2Z19ibG9nID4gbm9f
Y29uZykgDQorCQlzb2Z0bmV0X2RhdGFbY3B1XS5jbmdfbGV2ZWw9IEJMR19D
TkdfTE9XOw0KKwllbHNlICAvKiBubyBjb25nZXN0aW9uICovDQorCQlzb2Z0
bmV0X2RhdGFbY3B1XS5jbmdfbGV2ZWw9QkxHX0NOR19OT05FOw0KKw0KKwlz
b2Z0bmV0X2RhdGFbY3B1XS5hdmdfYmxvZz1hdmdfYmxvZzsNCisNCit9DQor
DQorI2lmZGVmIG9mZmxpbmVfc2FtcA0KK3N0YXRpYyB2b2lkIHNhbXBsZV9x
dWV1ZSh1bnNpZ25lZCBsb25nIGR1bW15KQ0KK3sNCisvKiAxMCBtcyAwciAx
bXMgLS0gaSBkb250IGNhcmUgLS0gSkhTICovDQorCWludCBuZXh0X3RpY2s9
MTsNCisJaW50IGNwdT1zbXBfcHJvY2Vzc29yX2lkKCk7DQorCWdldF9zYW1w
bGVfc3RhdHMoY3B1KTsNCisJbmV4dF90aWNrKz1qaWZmaWVzOw0KKwltb2Rf
dGltZXIoJnNhbXBfdGltZXIsIG5leHRfdGljayk7DQorfQ0KKyNlbmRpZg0K
Kw0KKw0KIC8qKg0KICAqCW5ldGlmX3J4CS0JcG9zdCBidWZmZXIgdG8gdGhl
IG5ldHdvcmsgY29kZQ0KICAqCUBza2I6IGJ1ZmZlciB0byBwb3N0DQpAQCAt
MTAyMiw5ICsxMDkzLDE4IEBADQogICoJdGhlIHVwcGVyIChwcm90b2NvbCkg
bGV2ZWxzIHRvIHByb2Nlc3MuICBJdCBhbHdheXMgc3VjY2VlZHMuIFRoZSBi
dWZmZXINCiAgKgltYXkgYmUgZHJvcHBlZCBkdXJpbmcgcHJvY2Vzc2luZyBm
b3IgY29uZ2VzdGlvbiBjb250cm9sIG9yIGJ5IHRoZSANCiAgKglwcm90b2Nv
bCBsYXllcnMuDQorICogICAgICANCisgKglyZXR1cm4gdmFsdWVzOg0KKyAq
CUJMR19DTkdfTk9ORQkobm8gY29uZ2VzdGlvbikgICAgICAgICAgIA0KKyAq
CUJMR19DTkdfTE9XICAgICAobG93IGNvbmdlc3Rpb24pIA0KKyAqCUJMR19D
TkdfTU9EICAgICAobW9kZXJhdGUgY29uZ2VzdGlvbikNCisgKglCTEdfQ05H
X0hJR0ggICAgKGhpZ2ggY29uZ2VzdGlvbikgDQorICoJQkxHX0NOR19EUk9Q
ICAgIChwYWNrZXQgd2FzIGRyb3BwZWQpDQorICogICAgICANCisgKiAgICAg
IA0KICAqLw0KIA0KLXZvaWQgbmV0aWZfcngoc3RydWN0IHNrX2J1ZmYgKnNr
YikNCitpbnQgbmV0aWZfcngoc3RydWN0IHNrX2J1ZmYgKnNrYikNCiB7DQog
CWludCB0aGlzX2NwdSA9IHNtcF9wcm9jZXNzb3JfaWQoKTsNCiAJc3RydWN0
IHNvZnRuZXRfZGF0YSAqcXVldWU7DQpAQCAtMTA0Myw2ICsxMTIzLDcgQEAN
CiAJbmV0ZGV2X3J4X3N0YXRbdGhpc19jcHVdLnRvdGFsKys7DQogCWlmIChx
dWV1ZS0+aW5wdXRfcGt0X3F1ZXVlLnFsZW4gPD0gbmV0ZGV2X21heF9iYWNr
bG9nKSB7DQogCQlpZiAocXVldWUtPmlucHV0X3BrdF9xdWV1ZS5xbGVuKSB7
DQorDQogCQkJaWYgKHF1ZXVlLT50aHJvdHRsZSkNCiAJCQkJZ290byBkcm9w
Ow0KIA0KQEAgLTEwNTQsMTEgKzExMzUsMTYgQEANCiAJCQlfX3NrYl9xdWV1
ZV90YWlsKCZxdWV1ZS0+aW5wdXRfcGt0X3F1ZXVlLHNrYik7DQogCQkJX19j
cHVfcmFpc2Vfc29mdGlycSh0aGlzX2NwdSwgTkVUX1JYX1NPRlRJUlEpOw0K
IAkJCWxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsNCi0JCQlyZXR1cm47DQor
I2lmbmRlZiBvZmZsaW5lX3NhbXANCisJCQlnZXRfc2FtcGxlX3N0YXRzKHRo
aXNfY3B1KTsNCisjZW5kaWYNCisJCQlyZXR1cm4gc29mdG5ldF9kYXRhW3Ro
aXNfY3B1XS5jbmdfbGV2ZWw7DQorDQogCQl9DQogDQogCQlpZiAocXVldWUt
PnRocm90dGxlKSB7DQogCQkJcXVldWUtPnRocm90dGxlID0gMDsNCisNCiAj
aWZkZWYgQ09ORklHX05FVF9IV19GTE9XQ09OVFJPTA0KIAkJCWlmIChhdG9t
aWNfZGVjX2FuZF90ZXN0KCZuZXRkZXZfZHJvcHBpbmcpKQ0KIAkJCQluZXRk
ZXZfd2FrZXVwKCk7DQpAQCAtMTA4MCw2ICsxMTY2LDggQEANCiAJbG9jYWxf
aXJxX3Jlc3RvcmUoZmxhZ3MpOw0KIA0KIAlrZnJlZV9za2Ioc2tiKTsNCisJ
cmV0dXJuIEJMR19DTkdfRFJPUDsNCisNCiB9DQogDQogLyogRGVsaXZlciBz
a2IgdG8gYW4gb2xkIHByb3RvY29sLCB3aGljaCBpcyBub3QgdGhyZWFkZWQg
d2VsbA0KQEAgLTEyOTIsMTIgKzEzODAsMjggQEANCiANCiAJCWlmIChidWdk
ZXQtLSA8IDAgfHwgamlmZmllcyAtIHN0YXJ0X3RpbWUgPiAxKQ0KIAkJCWdv
dG8gc29mdG5ldF9icmVhazsNCisNCisvKiANCisqLw0KKyNpZmRlZiBDT05G
SUdfTkVUX0hXX0ZMT1dDT05UUk9MDQorCWlmIChxdWV1ZS0+dGhyb3R0bGUg
JiYgcXVldWUtPmlucHV0X3BrdF9xdWV1ZS5xbGVuIDwgbm9fY29uZ190aHJl
c2ggKSB7DQorCQlpZiAoYXRvbWljX2RlY19hbmRfdGVzdCgmbmV0ZGV2X2Ry
b3BwaW5nKSkgIHsNCisJCQlxdWV1ZS0+dGhyb3R0bGUgPSAwOw0KKwkJCW5l
dGRldl93YWtldXAoKTsNCisJCQlnb3RvIHNvZnRuZXRfYnJlYWs7DQorCQl9
DQorDQorCX0NCisjZW5kaWYNCisNCisNCiAJfQ0KIAlicl9yZWFkX3VubG9j
ayhCUl9ORVRQUk9UT19MT0NLKTsNCiANCiAJbG9jYWxfaXJxX2Rpc2FibGUo
KTsNCiAJaWYgKHF1ZXVlLT50aHJvdHRsZSkgew0KIAkJcXVldWUtPnRocm90
dGxlID0gMDsNCisNCiAjaWZkZWYgQ09ORklHX05FVF9IV19GTE9XQ09OVFJP
TA0KIAkJaWYgKGF0b21pY19kZWNfYW5kX3Rlc3QoJm5ldGRldl9kcm9wcGlu
ZykpDQogCQkJbmV0ZGV2X3dha2V1cCgpOw0KQEAgLTI0MTgsNiArMjUyMiw3
IEBADQogaW50IF9faW5pdCBuZXRfZGV2X2luaXQodm9pZCkNCiB7DQogCXN0
cnVjdCBuZXRfZGV2aWNlICpkZXYsICoqZHA7DQorDQogCWludCBpOw0KIA0K
ICNpZmRlZiBDT05GSUdfTkVUX1NDSEVEDQpAQCAtMjQzNCw2ICsyNTM5LDgg
QEANCiAJCXF1ZXVlID0gJnNvZnRuZXRfZGF0YVtpXTsNCiAJCXNrYl9xdWV1
ZV9oZWFkX2luaXQoJnF1ZXVlLT5pbnB1dF9wa3RfcXVldWUpOw0KIAkJcXVl
dWUtPnRocm90dGxlID0gMDsNCisJCXF1ZXVlLT5jbmdfbGV2ZWwgPSAwOw0K
KwkJcXVldWUtPmF2Z19ibG9nID0gMTA7IC8qIGFyYml0cmFyeSBub24temVy
byAqLw0KIAkJcXVldWUtPmNvbXBsZXRpb25fcXVldWUgPSBOVUxMOw0KIAl9
DQogCQ0KQEAgLTI0NDIsNiArMjU0OSwxMiBAQA0KIAlORVRfUFJPRklMRV9S
RUdJU1RFUihkZXZfcXVldWVfeG1pdCk7DQogCU5FVF9QUk9GSUxFX1JFR0lT
VEVSKHNvZnRuZXRfcHJvY2Vzcyk7DQogI2VuZGlmDQorDQorI2lmZGVmIG9m
ZmxpbmVfc2FtcA0KKwlzYW1wX3RpbWVyLmV4cGlyZXM9amlmZmllcysoMTAg
KiBIWik7DQorCWFkZF90aW1lcigmc2FtcF90aW1lcik7DQorI2VuZGlmDQor
DQogCS8qDQogCSAqCUFkZCB0aGUgZGV2aWNlcy4NCiAJICoJSWYgdGhlIGNh
bGwgdG8gZGV2LT5pbml0IGZhaWxzLCB0aGUgZGV2IGlzIHJlbW92ZWQNCkBA
IC0yNDk5LDYgKzI2MTIsNyBAQA0KICNpZmRlZiBDT05GSUdfUFJPQ19GUw0K
IAlwcm9jX25ldF9jcmVhdGUoImRldiIsIDAsIGRldl9nZXRfaW5mbyk7DQog
CWNyZWF0ZV9wcm9jX3JlYWRfZW50cnkoIm5ldC9zb2Z0bmV0X3N0YXQiLCAw
LCAwLCBkZXZfcHJvY19zdGF0cywgTlVMTCk7DQorDQogI2lmZGVmIFdJUkVM
RVNTX0VYVA0KIAlwcm9jX25ldF9jcmVhdGUoIndpcmVsZXNzIiwgMCwgZGV2
X2dldF93aXJlbGVzc19pbmZvKTsNCiAjZW5kaWYJLyogV0lSRUxFU1NfRVhU
ICovDQotLS0gbGludXgvaW5jbHVkZS9saW51eC9uZXRkZXZpY2UuaC5vcmln
CUZyaSBTZXAgIDggMTU6NTM6NTMgMjAwMA0KKysrIGxpbnV4L2luY2x1ZGUv
bGludXgvbmV0ZGV2aWNlLmgJVHVlIFNlcCAxMiAyMDowMToyNSAyMDAwDQpA
QCAtNDcsNiArNDcsMTMgQEANCiAJCQkJCSAgIChUQyB1c2Ugb25seSAtIGRl
dl9xdWV1ZV94bWl0DQogCQkJCQkgICByZXR1cm5zIHRoaXMgYXMgTkVUX1hN
SVRfU1VDQ0VTUykgKi8NCiANCisvKiBCYWNrbG9nIGNvbmdlc3Rpb24gbGV2
ZWxzICovDQorI2RlZmluZSBCTEdfQ05HX05PTkUJCTEgICAvKiBrZWVwICdl
bSBjb21pbmcsIGJhYnkgKi8NCisjZGVmaW5lIEJMR19DTkdfTE9XCQkyICAg
Lyogc3Rvcm0gYWxlcnQsIGp1c3QgaW4gY2FzZSAqLw0KKyNkZWZpbmUgQkxH
X0NOR19NT0QJCTMgICAvKiBTdG9ybSBvbiBpdHMgd2F5ISAqLw0KKyNkZWZp
bmUgQkxHX0NOR19ISUdICQk1ICAgLyogVGhlIFRzdW5hbWkgaXMgaGVyZSwg
Ym95cyBhbmQgZ2lybHMgKi8NCisjZGVmaW5lIEJMR19DTkdfRFJPUAkJLTEg
IC8qIHRvbyBsYXRlLG1vbiBhbWkhIHBhY2tldCBkcm9wcGVkICovDQorDQog
I2RlZmluZSBuZXRfeG1pdF9lcnJubyhlKQkoKGUpICE9IE5FVF9YTUlUX0NO
ID8gLUVOT0JVRlMgOiAwKQ0KIA0KICNlbmRpZg0KQEAgLTQ0MCw2ICs0NDcs
OCBAQA0KIHN0cnVjdCBzb2Z0bmV0X2RhdGENCiB7DQogCWludAkJCXRocm90
dGxlOw0KKwlpbnQJCQljbmdfbGV2ZWw7DQorCWludAkJCWF2Z19ibG9nOw0K
IAlzdHJ1Y3Qgc2tfYnVmZl9oZWFkCWlucHV0X3BrdF9xdWV1ZTsNCiAJc3Ry
dWN0IG5ldF9kZXZpY2UJKm91dHB1dF9xdWV1ZTsNCiAJc3RydWN0IHNrX2J1
ZmYJCSpjb21wbGV0aW9uX3F1ZXVlOw0KQEAgLTUyNiw3ICs1MzUsNyBAQA0K
IA0KIGV4dGVybiB2b2lkCQluZXRfY2FsbF9yeF9hdG9taWModm9pZCAoKmZu
KSh2b2lkKSk7DQogI2RlZmluZSBIQVZFX05FVElGX1JYIDENCi1leHRlcm4g
dm9pZAkJbmV0aWZfcngoc3RydWN0IHNrX2J1ZmYgKnNrYik7DQorZXh0ZXJu
IGludAkJbmV0aWZfcngoc3RydWN0IHNrX2J1ZmYgKnNrYik7DQogZXh0ZXJu
IGludAkJZGV2X2lvY3RsKHVuc2lnbmVkIGludCBjbWQsIHZvaWQgKik7DQog
ZXh0ZXJuIGludAkJZGV2X2NoYW5nZV9mbGFncyhzdHJ1Y3QgbmV0X2Rldmlj
ZSAqLCB1bnNpZ25lZCk7DQogZXh0ZXJuIHZvaWQJCWRldl9xdWV1ZV94bWl0
X25pdChzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBzdHJ1Y3QgbmV0X2RldmljZSAq
ZGV2KTsNCkBAIC02MjgsNiArNjM3LDcgQEANCiBleHRlcm4gdm9pZAkJbmV0
ZGV2X3VucmVnaXN0ZXJfZmMoaW50IGJpdCk7DQogZXh0ZXJuIGludAkJbmV0
ZGV2X21heF9iYWNrbG9nOw0KIGV4dGVybiB1bnNpZ25lZCBsb25nCW5ldGRl
dl9mY194b2ZmOw0KK2V4dGVybiBhdG9taWNfdCBuZXRkZXZfZHJvcHBpbmc7
DQogZXh0ZXJuIGludAkJbmV0ZGV2X3NldF9tYXN0ZXIoc3RydWN0IG5ldF9k
ZXZpY2UgKmRldiwgc3RydWN0IG5ldF9kZXZpY2UgKm1hc3Rlcik7DQogI2lm
ZGVmIENPTkZJR19ORVRfRkFTVFJPVVRFDQogZXh0ZXJuIGludAkJbmV0ZGV2
X2Zhc3Ryb3V0ZTsNCi0tLSAvdXNyL3NyYy9saW51eC9uZXQvbmV0c3ltcy5j
CTIwMDAvMDkvMTYgMjM6MDA6MzMJMS4xDQorKysgL3Vzci9zcmMvbGludXgv
bmV0L25ldHN5bXMuYwkyMDAwLzA5LzE2IDIzOjAxOjI4DQpAQCAtNDkwLDYg
KzQ5MCw3IEBADQogRVhQT1JUX1NZTUJPTChkZXZfaW9jdGwpOw0KIEVYUE9S
VF9TWU1CT0woZGV2X3F1ZXVlX3htaXQpOw0KICNpZmRlZiBDT05GSUdfTkVU
X0hXX0ZMT1dDT05UUk9MDQorRVhQT1JUX1NZTUJPTChuZXRkZXZfZHJvcHBp
bmcpOw0KIEVYUE9SVF9TWU1CT0wobmV0ZGV2X3JlZ2lzdGVyX2ZjKTsNCiBF
WFBPUlRfU1lNQk9MKG5ldGRldl91bnJlZ2lzdGVyX2ZjKTsNCiBFWFBPUlRf
U1lNQk9MKG5ldGRldl9mY194b2ZmKTsNCg==
---559023410-851401618-969327077=:3641--

From owner-netdev@oss.sgi.com Mon Sep 18 19:02:56 2000
Received:  by oss.sgi.com id <S42284AbQISCCg>;
	Mon, 18 Sep 2000 19:02:36 -0700
Received: from pizda.ninka.net ([216.101.162.242]:63360 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42278AbQISCCQ>;
	Mon, 18 Sep 2000 19:02:16 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id SAA02155;
	Mon, 18 Sep 2000 18:49:42 -0700
Date:   Mon, 18 Sep 2000 18:49:42 -0700
Message-Id: <200009190149.SAA02155@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     hadi@cyberus.ca
CC:     kuznet@ms2.inr.ac.ru, Robert.Olsson@data.slu.se,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com, becker@scyld.com,
        eis@baty.hanse.de
In-reply-to: <Pine.GSO.4.20.0009182121310.3641-200000@shell.cyberus.ca>
	(message from jamal on Mon, 18 Sep 2000 21:31:17 -0400 (EDT))
Subject: Re: [PATCH/RFC] (long) network interface changes
References:  <Pine.GSO.4.20.0009182121310.3641-200000@shell.cyberus.ca>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date: Mon, 18 Sep 2000 21:31:17 -0400 (EDT)
   From: jamal <hadi@cyberus.ca>

   My testing with the included scheme (#ifdef RAND_LIE) indicates
   that fairness infact goes up; however, the overall throughput when
   only one interface is utilizing the system goes down under heavy to
   moderate congestion.  I am including it here as a way to highlight
   the problem. I think there could be better ways to do this.  Code
   is included and can be turned on by defining RAND_LIE in dev.c

Why not keep a counter per-device.

This counter is an atomic_t and initially zero.

When a packet is given to netif_rx and becomes part of the backlog
this counter is incremented.

When a packet leaves the backlog, this same counter is decremented.

You can use this counter to approximate queue percentages per-device
and use this to decide who gets the little white lies.

Questions are whether this will be cheaper than calling net_random()
occaisionally and actually more interesting would be a scheme which
did not hurt the single interface case. :-(

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Mon Sep 18 19:23:16 2000
Received:  by oss.sgi.com id <S42287AbQISCXG>;
	Mon, 18 Sep 2000 19:23:06 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:18890 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42278AbQISCWk>;
	Mon, 18 Sep 2000 19:22:40 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id WAA17535;
	Mon, 18 Sep 2000 22:22:38 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id WAA03727;
	Mon, 18 Sep 2000 22:22:39 -0400 (EDT)
Date:   Mon, 18 Sep 2000 22:22:38 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     "David S. Miller" <davem@redhat.com>
cc:     kuznet@ms2.inr.ac.ru, Robert.Olsson@data.slu.se,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com, becker@scyld.com,
        eis@baty.hanse.de
Subject: Re: [PATCH/RFC] (long) network interface changes
In-Reply-To: <200009190149.SAA02155@pizda.ninka.net>
Message-ID: <Pine.GSO.4.20.0009182202380.3693-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, 18 Sep 2000, David S. Miller wrote:

>    Date: Mon, 18 Sep 2000 21:31:17 -0400 (EDT)
>    From: jamal <hadi@cyberus.ca>
> 
>    My testing with the included scheme (#ifdef RAND_LIE) indicates
>    that fairness infact goes up; however, the overall throughput when
>    only one interface is utilizing the system goes down under heavy to
>    moderate congestion.  I am including it here as a way to highlight
>    the problem. I think there could be better ways to do this.  Code
>    is included and can be turned on by defining RAND_LIE in dev.c
> 
> Why not keep a counter per-device.
> 
> This counter is an atomic_t and initially zero.
> 
> When a packet is given to netif_rx and becomes part of the backlog
> this counter is incremented.
> 
> When a packet leaves the backlog, this same counter is decremented.
> 
> You can use this counter to approximate queue percentages per-device
> and use this to decide who gets the little white lies.
> Questions are whether this will be cheaper than calling net_random()

What you describe is _exactly_ one of the schemes we discussed.   
Maintaining that device state info is cheap.
You will need to consider the arrival rates, so you would sample the
(same way we do in the patch) and maintain the average queue-contrib,
per-device. The elegance required is in deciding the per-device quotas
dynamically incase some devices is not using up its quota.
Another scheme would be to do per-device queues ... soft-irq does a RR

We need to experiment, show some numbers. That code exposes the problem
and gives a less than optimal solution since no per-device state is
maintained. 

> occaisionally and actually more interesting would be a scheme which
> did not hurt the single interface case. :-(
> 

The dynamic sharing of the per-device quoatas would help.

cheers,
jamal



From owner-netdev@oss.sgi.com Mon Sep 18 23:27:57 2000
Received:  by oss.sgi.com id <S42301AbQISG1r>;
	Mon, 18 Sep 2000 23:27:47 -0700
Received: from mail.bieringer.de ([195.226.187.51]:25611 "HELO
        titan.bieringer.de") by oss.sgi.com with SMTP id <S42234AbQISG1d>;
	Mon, 18 Sep 2000 23:27:33 -0700
Received: (qmail 6590 invoked from network); 19 Sep 2000 06:27:30 -0000
Received: from p3e9921e8.dip.t-dialin.net (HELO worker.bieringer.de) (62.153.33.232)
  by mail.bieringer.de with SMTP; 19 Sep 2000 06:27:30 -0000
Message-Id: <5.0.0.25.0.20000919082728.029f3890@mail.bieringer.de>
X-Sender: list4peter@mail.bieringer.de (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date:   Tue, 19 Sep 2000 08:29:30 +0200
To:     Matti Aarnio <matti.aarnio@zmailer.org>, ychoi@us.ibm.com
From:   Peter Bieringer <pb@bieringer.de>
Subject: Re: ping source code
Cc:     netdev@oss.sgi.com
In-Reply-To: <20000918222026.A11669@mea-ext.zmailer.org>
References: <OFA0B67E2D.F2144B01-ON8525695E.0064F377@pok.ibm.com>
 <OFA0B67E2D.F2144B01-ON8525695E.0064F377@pok.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

At 21:20 18.09.2000, Matti Aarnio wrote:
>On Mon, Sep 18, 2000 at 02:23:36PM -0400, ychoi@us.ibm.com wrote:
> > Hello! I got your address from the MAINTAINERS list. I am looking for the
> > ping source code with -I (capitol I) option where I can specify a device
> > name (not an interface address). On Redhat 6.2, I ran "man ping" and found
> > out the option is available. I need to use the coding in one of my program.
> > I will appreciate if you return to me.
>
>$ rpm -qf /bin/ping
>iputils-20000121-2
>
>    Ok, so you should look for  iputils-*.src.rpm   package for the source.
>
>    Do you have any idea of how to open *.src.rpm files ?

rpm -qip packet-*.src.rpm

Mostly extracted to /usr/src/distribution/SOURCES|SPECS
tarball +  additional patches -> SOURCES
spec-file -> SPECS

Or take "mc" to dig into.

  Peter


From owner-netdev@oss.sgi.com Tue Sep 19 03:33:09 2000
Received:  by oss.sgi.com id <S42267AbQISKc7>;
	Tue, 19 Sep 2000 03:32:59 -0700
Received: from luna.tlmat.unican.es ([193.144.186.2]:29956 "EHLO
        luna.tlmat.unican.es") by oss.sgi.com with ESMTP id <S42234AbQISKcl>;
	Tue, 19 Sep 2000 03:32:41 -0700
Received: from centauro (lira.tlmat.unican.es [193.144.186.27]) by luna.tlmat.unican.es with SMTP (8.7.6/8.7.1) id MAA02079 for <netdev@oss.sgi.com>; Tue, 19 Sep 2000 12:42:52 +0200 (METDST)
Message-ID: <001801c02224$8fa07ac0$1bba90c1@tlmat.unican.es>
From:   =?iso-8859-1?B?UmFt824gQWf8ZXJv?= <ramon@tlmat.unican.es>
To:     <netdev@oss.sgi.com>
Subject: Giving priority to messages
Date:   Tue, 19 Sep 2000 12:29:54 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0015_01C02235.505913C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
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_0015_01C02235.505913C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

    Hi all,

    I'm working within an application which creates packets and sends =
them. To accomplish this I use the dev_queue_xmit function. At a fist =
stage, everything runs OK, but I would like also to give priority to =
these messages, in relation with other messages that the machine =
creates, so that they don't have to wait.

    I would be pleased if you could tell me how to assign this priority. =
I'm working with 2.2.14 kernel.

    Best regards.

    Ram=F3n

PD.- Please I wish to be personally CC'ed the answers/comments posted to =
the list in response to my posting



------=_NextPart_000_0015_01C02235.505913C0
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.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Hi all,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; I'm working within an application =
which=20
creates packets and sends them. To accomplish this I use the =
dev_queue_xmit=20
function. At a fist stage, everything runs OK, but I would like also to =
give=20
priority to these messages, in relation with other messages that the =
machine=20
creates, so that they don't have to wait.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; I would be pleased if you could =
tell me how=20
to assign this priority. I'm working with 2.2.14 kernel.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Best regards.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Ram=F3n</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>PD.- Please&nbsp;I wish to be personally CC'ed the=20
answers/comments posted to the list in response to&nbsp;my=20
posting<BR></DIV></FONT></FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0015_01C02235.505913C0--


From owner-netdev@oss.sgi.com Tue Sep 19 04:09:49 2000
Received:  by oss.sgi.com id <S42302AbQISLJa>;
	Tue, 19 Sep 2000 04:09:30 -0700
Received: from pop3.galileo.co.il ([199.203.130.130]:32149 "EHLO
        galileo5.galileo.co.il") by oss.sgi.com with ESMTP
	id <S42234AbQISLJI>; Tue, 19 Sep 2000 04:09:08 -0700
Received: from galileo.co.il (rabeeh@linux2.galileo.co.il [10.2.40.2])
	by galileo.co.il (8.8.5/8.8.5) with ESMTP id OAA26032
	for <netdev@oss.sgi.com>; Tue, 19 Sep 2000 14:09:29 +0200 (GMT-2)
Message-ID: <39C7AD0D.84CEDBD9@galileo.co.il>
Date:   Tue, 19 Sep 2000 14:14:37 -0400
From:   Rabeeh Khoury <rabeeh@galileo.co.il>
Reply-To: rabeeh@galileo.co.il
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev <netdev@oss.sgi.com>
Subject: forwarding packets
Content-Type: multipart/mixed;
 boundary="------------EB22366B16D4BC586A0A247E"
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.
--------------EB22366B16D4BC586A0A247E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi All

I am working on a Galileo Technology evaluation board. I'm writing
ethernet driver for our embedded systems and I have to ethernet ports.

I need to ask if there is a way for implementing the following scenario
for the ethernet drivers to be activated as two ethernet ports router :

1.. The ethernet driver receives a packet
2.. The ethernet driver checks if the packet should be forwarded to
another interface. The checking is done by query to the kernel routing
table.
3.. If the packet should be forwarded, the ethernet driver queues the
packet to the destination interface with slight changes (source and
destination MAC addresses).

If this scenario possible, please send me the functions that I should
use. (dev_queue_xmit for queing a packet to another interface ??!!)

The main motive in this scenario is that I don't want that the packet to
be handed to the kernel IP stack, then to decide if it should be routed
or not ; I want from the ethernet driver to know if the packet should be
routed or not, and if to be routed to which interface.

Another question :
How can I know from the sk_buff when handed to the ethernet driver, if
it is a routed packet or it's origin is from the local CPU ?

p.s. I'm using kernel 2.2.14 (MIPS based CPU)

Regards,
Rabea Khoury


--------------EB22366B16D4BC586A0A247E
Content-Type: text/x-vcard; charset=us-ascii;
 name="rabeeh.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Rabeeh Khoury
Content-Disposition: attachment;
 filename="rabeeh.vcf"

begin:vcard 
n:Khoury;Rabeeh
x-mozilla-html:FALSE
org:Galileo Technology;Software Department
adr:;;;;;;
version:2.1
email;internet:rabeeh@galileo.co.il
title:Development Engineer
x-mozilla-cpt:;-31712
fn:Rabeeh Khoury
end:vcard

--------------EB22366B16D4BC586A0A247E--


From owner-netdev@oss.sgi.com Tue Sep 19 05:31:51 2000
Received:  by oss.sgi.com id <S42274AbQISMbb>;
	Tue, 19 Sep 2000 05:31:31 -0700
Received: from horus.its.uow.edu.au ([130.130.68.25]:16277 "EHLO
        horus.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42234AbQISMbH>;
	Tue, 19 Sep 2000 05:31:07 -0700
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 XAA11563;
	Tue, 19 Sep 2000 23:30:34 +1100 (EST)
Message-ID: <39C75CB6.E86C55F@uow.edu.au>
Date:   Tue, 19 Sep 2000 23:31:50 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8-pre1 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Jeff Garzik <jgarzik@mandrakesoft.com>
CC:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        netdev@oss.sgi.com, "David S. Miller" <davem@redhat.com>,
        jes@linuxcare.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
References: <39C5D263.8DA31C03@mandrakesoft.com>
Content-Type: multipart/mixed;
 boundary="------------0BBE9C0A040819DBB90D43E6"
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.
--------------0BBE9C0A040819DBB90D43E6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jeff Garzik wrote:
> 
> This patch, against 2.4.0-test9-pre2, moves ethtool.h from the private
> domain of the sparc ports into include/linux.  This publishes an
> existing interface, and has been discussed before.  (search past lkml
> subject headers for "media tool" and "ethtool")
> 
> This updated patch should take some of the past threads into account.
> The differences from the current sparc ethtool.h are:
> 
> * bitmask for advertising as well as supported media types
> * interrupt mitigation hints max{tx,rx}pkt (Jes suggestion)
> * four reserved u32 slots for future expansion
> * assigned an ioctl: SIOCETHTOOL (0x8944)
> 

This is good. It would be useful to have this in place ASAP so driver
authors have something to look at and to work against.

I've made some edits (revised patch attached here).

* With this interface I don't see a way in which one can force some
settings but leave others unforced.  Suppose, for example, that I wish
to force 10mbps but to leave the setting of the transceiver type,
duplex, etc alone (ie: up to the driver/hardware to determine the value
of these).

If you do an ETHTOOL_SSET/modify/ETHTOOL_SGET on the interface you'll
end up *forcing* all these settings into whatever state they happened to
be in when you did the read, no?

So I added the `force_mask' which should be tested by the ETHTOOL_SSET
handler to decide which fields are actually being forced.

When the driver receives a ETHTOOL_SGET it should populate `force_mask'
to indicate to the caller which fields are currently forced.

* I added SUPPORTED_MAC_FLOWCTRL/ADVERTISED_MAC_FLOWCTRL for advertising
of 802.3x MAC-layer flow control.

* I added the `flow_ctrl' field to say whether we want to enable/disable
this.

Other comments:

* There don't seem to be enough port types and transceiver types. 
10base2? BNC? 100baseTx/100baseFX?

* Regarding the ADVERTISED bits.  Are these designed to read back what
we're currently advertising, or are they designed to allow us to force
what is to be advertised?  Both, I guess.

* maxtxpkt and maxrxpkt seem highly specific to particular hardware and
particular drivers.  Plus there are a large range of other
driver-specific performance tunables which are typically controlled by
module parms.  Why pick these two?

It may be better to bury this sort of thing into a device-specific
anonymous field.  Shrug - don't bother: I wouldn't expect anyone to
really use these things because it's such a PITA to tear down all the
driver data structures and rebuild them.

* Are you really, really sure about the alignment issues with struct
ethtool_cmd?  It strikes me that burying a short and five chars in among
a bunch of longs is asking for trouble.  Suppose the caller is using a
different compiler?  If you're not sure, make 'em all u32 :)



On a related topic, it offends me that when you unplug the RJ45 from a
win2k machine it pops up a little box telling you your network has
disappeared.  We can't do that.

At present, SIOCGIFFLAGS returns an amalgam of __LINK_STATE_START and
__LINK_STATE_NOCARRIER in IFF_RUNNING.  We need to separate these out so
applications can query __LINK_STATE_NOCARRIER independently.  We also
need a select()able interface so changes in carrier can be monitored.

The users of a select()able carrier detect would be desktop UIs and the
high-availability guys.  The latter is a guess - I don't really know if
people who are concerned about failover would find a carrier-lost
indication useful.  TBD.
--------------0BBE9C0A040819DBB90D43E6
Content-Type: text/plain; charset=us-ascii;
 name="ethtool.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ethtool.patch"

--- linux-2.4.0-test9-pre4/include/linux/ethtool.h	Thu Jan  1 10:00:00 1970
+++ linux-akpm/include/linux/ethtool.h	Tue Sep 19 23:09:38 2000
@@ -0,0 +1,114 @@
+/* $Id: ethtool.h,v 1.1.186.1 2000/09/16 20:13:14 jgarzik Exp $
+ * ethtool.h: Defines for Linux ethtool.
+ *
+ * Copyright (C) 1998 David S. Miller (davem@redhat.com)
+ */
+
+#ifndef _LINUX_ETHTOOL_H
+#define _LINUX_ETHTOOL_H
+
+/* This should work for both 32 and 64 bit userland. */
+struct ethtool_cmd {
+	u32	cmd;
+	u32	force_mask;	/* Which fieldswe wish to force */
+	u32	supported;	/* Features this interface supports */
+	u32	advertising;	/* Features this interface advertises */
+	u16	speed;		/* The forced speed, 10Mb, 100Mb, gigabit */
+	u8	duplex;		/* Duplex, half or full */
+	u8	flow_ctrl;	/* 802.3x flow control */
+	u8	port;		/* Which connector port */
+	u8	phy_address;
+	u8	transceiver;	/* Which tranceiver to use */
+	u8	autoneg;	/* Enable or disable autonegotiation */
+	u32	maxtxpkt;	/* Tx pkts before generating tx int */
+	u32	maxrxpkt;	/* Rx pkts before generating rx int */
+	u32	reserved[4];
+};
+
+
+/* CMDs currently supported */
+#define ETHTOOL_GSET		0x00000001 /* Get settings, non-privileged. */
+#define ETHTOOL_SSET		0x00000002 /* Set settings, privileged. */
+
+/* compatibility with older code */
+#define SPARC_ETH_GSET		ETHTOOL_GSET
+#define SPARC_ETH_SSET		ETHTOOL_SSET
+
+/* Bits in ethtool_cmd.force_mask */
+#define ETHTOOL_FORCE_ADVERTISED	(1 << 0)
+#define ETHTOOL_FORCE_SPEED		(1 << 1)
+#define ETHTOOL_FORCE_DUPLEX		(1 << 2)
+#define ETHTOOL_FORCE_FLOWCTRL		(1 << 3)
+#define ETHTOOL_FORCE_PORT		(1 << 4)
+#define ETHTOOL_FORCE_XCVR		(1 << 5)
+#define ETHTOOL_FORCE_AUTONEG		(1 << 6)
+#define ETHTOOL_FORCE_MAXTXPKT		(1 << 7)
+#define ETHTOOL_FORCE_MAXRXPKT		(1 << 8)
+
+/* Indicates what features are supported by the interface. */
+#define SUPPORTED_10baseT_Half		(1 << 0)
+#define SUPPORTED_10baseT_Full		(1 << 1)
+#define SUPPORTED_100baseT_Half		(1 << 2)
+#define SUPPORTED_100baseT_Full		(1 << 3)
+#define SUPPORTED_1000baseT_Half	(1 << 4)
+#define SUPPORTED_1000baseT_Full	(1 << 5)
+#define SUPPORTED_Autoneg		(1 << 6)
+#define SUPPORTED_TP			(1 << 7)
+#define SUPPORTED_AUI			(1 << 8)
+#define SUPPORTED_MII			(1 << 9)
+#define SUPPORTED_FIBRE			(1 << 10)
+#define SUPPORTED_MAC_FLOWCTRL		(1 << 11)
+
+/* Indicates what features are advertised by the interface. */
+#define ADVERTISED_10baseT_Half		(1 << 0)
+#define ADVERTISED_10baseT_Full		(1 << 1)
+#define ADVERTISED_100baseT_Half	(1 << 2)
+#define ADVERTISED_100baseT_Full	(1 << 3)
+#define ADVERTISED_1000baseT_Half	(1 << 4)
+#define ADVERTISED_1000baseT_Full	(1 << 5)
+#define ADVERTISED_Autoneg		(1 << 6)
+#define ADVERTISED_TP			(1 << 7)
+#define ADVERTISED_AUI			(1 << 8)
+#define ADVERTISED_MII			(1 << 9)
+#define ADVERTISED_FIBRE		(1 << 10)
+#define ADVERTISED_MAC_FLOWCTRL		(1 << 11)
+
+/* The following are all involved in forcing a particular link
+ * mode for the device for setting things.  When getting the
+ * devices settings, these indicate the current mode and whether
+ * it was foced up into this mode or autonegotiated.
+ */
+
+/* The forced speed, 10Mb, 100Mb, gigabit. */
+#define SPEED_10		10
+#define SPEED_100		100
+#define SPEED_1000		1000
+
+/* Duplex, half or full. */
+#define DUPLEX_HALF		0x00
+#define DUPLEX_FULL		0x01
+
+/* 802.3x flow control: on or off */
+#define FLOWCTRL_OFF		0x00
+#define FLOWCTRL_ON		0x01
+
+/* Which connector port. */
+#define PORT_TP			0x00
+#define PORT_AUI		0x01
+#define PORT_MII		0x02
+#define PORT_FIBRE		0x03
+
+/* Which tranceiver to use. */
+#define XCVR_INTERNAL		0x00
+#define XCVR_EXTERNAL		0x01
+#define XCVR_DUMMY1		0x02
+#define XCVR_DUMMY2		0x03
+#define XCVR_DUMMY3		0x04
+
+/* Enable or disable autonegotiation.  If this is set to enable,
+ * the forced link modes above are completely ignored.
+ */
+#define AUTONEG_DISABLE		0x00
+#define AUTONEG_ENABLE		0x01
+
+#endif /* _LINUX_ETHTOOL_H */
--- linux-2.4.0-test9-pre4/drivers/net/sunhme.c	Sat Sep  9 16:19:26 2000
+++ linux-akpm/drivers/net/sunhme.c	Tue Sep 19 22:23:56 2000
@@ -24,6 +24,7 @@
 #include <linux/string.h>
 #include <linux/delay.h>
 #include <linux/init.h>
+#include <linux/ethtool.h>
 #include <asm/system.h>
 #include <asm/bitops.h>
 #include <asm/io.h>
@@ -41,7 +42,6 @@
 #ifndef __sparc_v9__
 #include <asm/io-unit.h>
 #endif
-#include <asm/ethtool.h>
 #include <asm/uaccess.h>
 
 #include <linux/netdevice.h>
--- linux-2.4.0-test9-pre4/include/asm-sparc/ethtool.h	Tue Feb  1 18:37:19 2000
+++ linux-akpm/include/asm-sparc/ethtool.h	Thu Jan  1 10:00:00 1970
@@ -1,79 +0,0 @@
-/* $Id: ethtool.h,v 1.2 2000/01/31 04:59:17 davem Exp $
- * ethtool.h: Defines for SparcLinux ethtool.
- *
- * Copyright (C) 1998 David S. Miller (davem@redhat.com)
- */
-
-#ifndef _SPARC_ETHTOOL_H
-#define _SPARC_ETHTOOL_H
-
-/* We do things like this so it does not matter what kernel
- * headers you have on your system etc.
- */
-#undef SIOCETHTOOL
-#define SIOCETHTOOL	(SIOCDEVPRIVATE + 0x0f)
-
-/* This should work for both 32 and 64 bit userland. */
-struct ethtool_cmd {
-	u32	cmd;
-	u32	supported;
-	u16	speed;
-	u8	duplex;
-	u8	port;
-	u8	phy_address;
-	u8	transceiver;
-	u8	autoneg;
-};
-
-/* CMDs currently supported */
-#define SPARC_ETH_GSET		0x00000001	/* Get settings, non-privileged. */
-#define SPARC_ETH_SSET		0x00000002	/* Set settings, privileged. */
-
-/* Indicates what features are supported by the interface. */
-#define SUPPORTED_10baseT_Half		0x00000001
-#define SUPPORTED_10baseT_Full		0x00000002
-#define SUPPORTED_100baseT_Half		0x00000004
-#define SUPPORTED_100baseT_Full		0x00000008
-#define SUPPORTED_1000baseT_Half	0x00000010
-#define SUPPORTED_1000baseT_Full	0x00000020
-#define SUPPORTED_Autoneg		0x00000040
-#define SUPPORTED_TP			0x00000080
-#define SUPPORTED_AUI			0x00000100
-#define SUPPORTED_MII			0x00000200
-#define SUPPORTED_FIBRE			0x00000400
-
-/* The following are all involved in forcing a particular link
- * mode for the device for setting things.  When getting the
- * devices settings, these indicate the current mode and whether
- * it was foced up into this mode or autonegotiated.
- */
-
-/* The forced speec, 10Mb, 100Mb, gigabit. */
-#define SPEED_10		10
-#define SPEED_100		100
-#define SPEED_1000		1000
-
-/* Duplex, half or full. */
-#define DUPLEX_HALF		0x00
-#define DUPLEX_FULL		0x01
-
-/* Which connector port. */
-#define PORT_TP			0x00
-#define PORT_AUI		0x01
-#define PORT_MII		0x02
-#define PORT_FIBRE		0x03
-
-/* Which tranceiver to use. */
-#define XCVR_INTERNAL		0x00
-#define XCVR_EXTERNAL		0x01
-#define XCVR_DUMMY1		0x02
-#define XCVR_DUMMY2		0x03
-#define XCVR_DUMMY3		0x04
-
-/* Enable or disable autonegotiation.  If this is set to enable,
- * the forced link modes above are completely ignored.
- */
-#define AUTONEG_DISABLE		0x00
-#define AUTONEG_ENABLE		0x01
-
-#endif /* _SPARC_ETHTOOL_H */
--- linux-2.4.0-test9-pre4/include/asm-sparc64/ethtool.h	Tue Feb  1 18:37:19 2000
+++ linux-akpm/include/asm-sparc64/ethtool.h	Thu Jan  1 10:00:00 1970
@@ -1,79 +0,0 @@
-/* $Id: ethtool.h,v 1.2 2000/01/31 04:59:19 davem Exp $
- * ethtool.h: Defines for SparcLinux ethtool.
- *
- * Copyright (C) 1998 David S. Miller (davem@redhat.com)
- */
-
-#ifndef _SPARC64_ETHTOOL_H
-#define _SPARC64_ETHTOOL_H
-
-/* We do things like this so it does not matter what kernel
- * headers you have on your system etc.
- */
-#undef SIOCETHTOOL
-#define SIOCETHTOOL	(SIOCDEVPRIVATE + 0x0f)
-
-/* This should work for both 32 and 64 bit userland. */
-struct ethtool_cmd {
-	u32	cmd;
-	u32	supported;
-	u16	speed;
-	u8	duplex;
-	u8	port;
-	u8	phy_address;
-	u8	transceiver;
-	u8	autoneg;
-};
-
-/* CMDs currently supported */
-#define SPARC_ETH_GSET		0x00000001	/* Get settings, non-privileged. */
-#define SPARC_ETH_SSET		0x00000002	/* Set settings, privileged. */
-
-/* Indicates what features are supported by the interface. */
-#define SUPPORTED_10baseT_Half		0x00000001
-#define SUPPORTED_10baseT_Full		0x00000002
-#define SUPPORTED_100baseT_Half		0x00000004
-#define SUPPORTED_100baseT_Full		0x00000008
-#define SUPPORTED_1000baseT_Half	0x00000010
-#define SUPPORTED_1000baseT_Full	0x00000020
-#define SUPPORTED_Autoneg		0x00000040
-#define SUPPORTED_TP			0x00000080
-#define SUPPORTED_AUI			0x00000100
-#define SUPPORTED_MII			0x00000200
-#define SUPPORTED_FIBRE			0x00000400
-
-/* The following are all involved in forcing a particular link
- * mode for the device for setting things.  When getting the
- * devices settings, these indicate the current mode and whether
- * it was foced up into this mode or autonegotiated.
- */
-
-/* The forced speec, 10Mb, 100Mb, gigabit. */
-#define SPEED_10		10
-#define SPEED_100		100
-#define SPEED_1000		1000
-
-/* Duplex, half or full. */
-#define DUPLEX_HALF		0x00
-#define DUPLEX_FULL		0x01
-
-/* Which connector port. */
-#define PORT_TP			0x00
-#define PORT_AUI		0x01
-#define PORT_MII		0x02
-#define PORT_FIBRE		0x03
-
-/* Which tranceiver to use. */
-#define XCVR_INTERNAL		0x00
-#define XCVR_EXTERNAL		0x01
-#define XCVR_DUMMY1		0x02
-#define XCVR_DUMMY2		0x03
-#define XCVR_DUMMY3		0x04
-
-/* Enable or disable autonegotiation.  If this is set to enable,
- * the forced link modes above are completely ignored.
- */
-#define AUTONEG_DISABLE		0x00
-#define AUTONEG_ENABLE		0x01
-
-#endif /* _SPARC64_ETHTOOL_H */
--- linux-2.4.0-test9-pre4/include/linux/sockios.h	Sun Jan 23 06:54:57 2000
+++ linux-akpm/include/linux/sockios.h	Tue Sep 19 22:23:56 2000
@@ -71,7 +71,7 @@
 
 #define SIOCGIFTXQLEN	0x8942		/* Get the tx queue length	*/
 #define SIOCSIFTXQLEN	0x8943		/* Set the tx queue length 	*/
-
+#define SIOCETHTOOL	0x8944		/* Ethtool interface		*/
 
 /* ARP cache control calls. */
 		    /*  0x8950 - 0x8952  * obsolete calls, don't re-use */

--------------0BBE9C0A040819DBB90D43E6--


From owner-netdev@oss.sgi.com Tue Sep 19 13:19:14 2000
Received:  by oss.sgi.com id <S42314AbQISUTE>;
	Tue, 19 Sep 2000 13:19:04 -0700
Received: from pop.gmx.net ([194.221.183.20]:14289 "HELO mail.gmx.net")
	by oss.sgi.com with SMTP id <S42234AbQISUSn>;
	Tue, 19 Sep 2000 13:18:43 -0700
Received: (qmail 17367 invoked by uid 0); 19 Sep 2000 20:18:35 -0000
Received: from usuario1-36-172-28.dialup.uni2.es (HELO dustin) (62.36.172.28)
  by mail.gmx.net with SMTP; 19 Sep 2000 20:18:35 -0000
Message-ID: <008101c02276$fe4fc5a0$1cac243e@dustin>
From:   "howling@the.moon" <havanna_moon@gmx.net>
To:     "Andrew Morton" <andrewm@uow.edu.au>
Cc:     <netdev@oss.sgi.com>
References: <39C5D263.8DA31C03@mandrakesoft.com> <39C75CB6.E86C55F@uow.edu.au>
Subject: RE: PATCH 2.4.0.9.2: export ethtool interface
Date:   Tue, 19 Sep 2000 22:02:20 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

From: Andrew Morton <andrewm@uow.edu.au>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>;
<netdev@oss.sgi.com>; David S. Miller <davem@redhat.com>;
<jes@linuxcare.com>
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface


> The users of a select()able carrier detect would be desktop UIs and
the
> high-availability guys.  The latter is a guess - I don't really know
if
> people who are concerned about failover would find a carrier-lost
> indication useful.  TBD.
Routers have a tendency not to announce routes for networks

that are physically down, i miss that in linux. Mr. Becker

suggested using libmii was a no-no-never solution (up to a few

ms lockup of the machine per poll) for this issue. Select as

you suggest seems ideal.



HAND

 yon





From owner-netdev@oss.sgi.com Tue Sep 19 14:13:04 2000
Received:  by oss.sgi.com id <S42316AbQISVMz>;
	Tue, 19 Sep 2000 14:12:55 -0700
Received: from lox.sandelman.ottawa.on.ca ([209.151.24.2]:65014 "EHLO
        lox.sandelman.ottawa.on.ca") by oss.sgi.com with ESMTP
	id <S42234AbQISVMf>; Tue, 19 Sep 2000 14:12:35 -0700
Received: from pzero.sandelman.ottawa.on.ca (LOCALHOST [127.0.0.1])
	by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id RAA26200;
	Tue, 19 Sep 2000 17:12:28 -0400 (EDT)
Received: from morden.sandelman.ottawa.on.ca (localhost.sandelman.ottawa.on.ca [127.0.0.1])
	by pzero.sandelman.ottawa.on.ca (8.11.0+3.3W/8.11.0) with ESMTP id e8JFimf22474;
	Tue, 19 Sep 2000 09:45:42 -0600 (MDT)
Message-Id: <200009191545.e8JFimf22474@pzero.sandelman.ottawa.on.ca>
From:   mcr@solidum.com
To:     rabeeh@galileo.co.il
cc:     netdev <netdev@oss.sgi.com>
Subject: Re: forwarding packets 
In-reply-to: Your message of "Tue, 19 Sep 2000 14:14:37 EDT."
             <39C7AD0D.84CEDBD9@galileo.co.il> 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date:   Tue, 19 Sep 2000 09:43:54 -0600
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Rabeeh" == Rabeeh Khoury <rabeeh@galileo.co.il> writes:
    Rabeeh> I am working on a Galileo Technology evaluation board. I'm
    Rabeeh> writing ethernet driver for our embedded systems and I have to
    Rabeeh> ethernet ports. 

  You mean you are porting Linux to this board? Is this a PCI board on
a passive backplane, or do you have it in a slot in a Linux machine?

    Rabeeh> I need to ask if there is a way for implementing the following scenario
    Rabeeh> for the ethernet drivers to be activated as two ethernet ports router :

    Rabeeh> 1.. The ethernet driver receives a packet
    Rabeeh> 2.. The ethernet driver checks if the packet should be forwarded to
    Rabeeh> another interface. The checking is done by query to the kernel routing
    Rabeeh> table.
    Rabeeh> 3.. If the packet should be forwarded, the ethernet driver queues the
    Rabeeh> packet to the destination interface with slight changes (source and
    Rabeeh> destination MAC addresses).

    Rabeeh> If this scenario possible, please send me the functions that I should
    Rabeeh> use. (dev_queue_xmit for queing a packet to another interface ??!!)

  I don't know if this is "legal", and I understand that this will starve
user processes of CPU. 

  I've been success setting skb->dev to the device I want and calling
dev_queue_xmit() from my interrupt service routine. The routing/filtering is
done by our hardware, and results in an index in to a table of devices.

] Train travel features AC outlets with no take-off restrictions|gigabit is no[
]   Michael Richardson, Solidum Systems/while this plane is 45  |problem  with[
]     mcr@solidum.com   www.solidum.com\minutes late and cramped|PAX.port 1100[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [
  


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.5, an Emacs/PGP interface

iQB1AwUBOceJuI5hrHmwwFrtAQEGtQL/c5z0DnfJ6JXBXDLugKxTDLPwqD4ItaoR
iXMGHecovUbfv4sTAld0rsZyos5NTfYI5t405+shHmWZtZeR+mw2hDIFVBpQ8zHM
n7001IRD6esDohZS+fXrLi0DmaPaPgWM
=lj9F
-----END PGP SIGNATURE-----

From owner-netdev@oss.sgi.com Tue Sep 19 15:40:25 2000
Received:  by oss.sgi.com id <S42320AbQISWkP>;
	Tue, 19 Sep 2000 15:40:15 -0700
Received: from kogge.hanse.de ([192.76.134.17]:15372 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S42234AbQISWjs>;
	Tue, 19 Sep 2000 15:39:48 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id AAA81913;
	Wed, 20 Sep 2000 00:44:04 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id WAA17341;
	Tue, 19 Sep 2000 22:48:45 +0200
Date:   Tue, 19 Sep 2000 22:48:45 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200009192048.WAA17341@baty.hanse.de>
To:     hadi@cyberus.ca
CC:     alan@lxorguk.ukuu.org.uk, davem@redhat.com, kuznet@ms2.inr.ac.ru,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
In-reply-to: <Pine.GSO.4.20.0009172129060.979-100000@shell.cyberus.ca>
	(message from jamal on Sun, 17 Sep 2000 21:38:38 -0400 (EDT))
Subject: Re: Q: sock output serialization
References:  <Pine.GSO.4.20.0009172129060.979-100000@shell.cyberus.ca>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "jamal" == jamal  <hadi@cyberus.ca> writes:

    jamal> Packets in flight?

    >> In the extreme case, there could still arrive up to the window
    >> size frames.

    jamal> Assuming this depends on path latency and not some bad
    jamal> programming

Yes. Although the latter could also possible.

    jamal> BTW, earlier i lied: there is a way to tell if your packet
    jamal> will be dropped which is not very expensive:

    jamal> 	if (atomic_read(&netdev_dropping) /* packet will be
    jamal> dropped */

    jamal> but even this is 99% accurate in SMP.

Well, but better than knowing nothing about congestion state.
We could at least document in the x25iface.txt kernel doc that driver
authors should check this before acknowledging frames.

Henner



From owner-netdev@oss.sgi.com Tue Sep 19 15:42:25 2000
Received:  by oss.sgi.com id <S42324AbQISWmP>;
	Tue, 19 Sep 2000 15:42:15 -0700
Received: from kogge.hanse.de ([192.76.134.17]:17676 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S42234AbQISWmG>;
	Tue, 19 Sep 2000 15:42:06 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id AAA81935;
	Wed, 20 Sep 2000 00:46:16 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id AAA17587;
	Wed, 20 Sep 2000 00:15:34 +0200
Date:   Wed, 20 Sep 2000 00:15:34 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200009192215.AAA17587@baty.hanse.de>
To:     hadi@cyberus.ca
CC:     davem@redhat.com, kuznet@ms2.inr.ac.ru, Robert.Olsson@data.slu.se,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com, becker@scyld.com
In-reply-to: <Pine.GSO.4.20.0009182121310.3641-200000@shell.cyberus.ca>
	(message from jamal on Mon, 18 Sep 2000 21:31:17 -0400 (EDT))
Subject: Re: [PATCH/RFC] (long) network interface changes
References:  <Pine.GSO.4.20.0009182121310.3641-200000@shell.cyberus.ca>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "jamal" == jamal  <hadi@cyberus.ca> writes:

[...]

Nice introduction!

    jamal> The driver uses the feedback information to intelligently
    jamal> adjust its sending rate.  (i.e reduce or increase calls to
    jamal> netif_rx() or send a congestion-experienced frame to its
    jamal> peer eg in X.25).  In the sample tulip driver, dynamic

Just a clarification (for the next version ;): it´s not really a
congestion notification. It is just a `receiver' busy condition.
LAPB is not designed for congestable links and cannot really report
that congestion occured. It can only delay acknowledgement (and
communicate rx_busy state to the peer). The retransmission was really
only designed for occasionally recovering from transmission error
caused by line noise. Once a packet has been lost, all packets (even
those already arrived after the lost one) must be retransmitted. There is
nothing like selcetive acknolegment. Thus, although LAPB can recover from
packet loss caused by congestion, it will not react in a manner adapted
to the congestion state. For minimizing possible confusion about the
different X.25 layers, I´d suggest to eplicitly call it `LAPB
datalink layer of X.25´ in future versions of the document.
 
     jamal> I have experimented with two schemes: one which samples the
    jamal> queue via a timer and one which does it per-packet and
    jamal> found that the per-packet sampler gave better results (more
    jamal> samples, Shannon's theorem applies).  It didnt matter
    jamal> whether HZ was 100 or 1024 during the tests.  The measure
    jamal> of "better" was throughput.

Nice. I think such a kind of fair input queueing would be an important
features because that allows to offer a highly reliable netif() to
slow links which are slow, but inefficient to handle congestion
(like X.25 LAPB datalink protocol). Network interfaces could trade
reliablilty for speed.

Another issue: Some protocols designed for congestable links support
forward and/or backward congestion notification (e.g. frame relay, I thing
DECnet and IPV6 also can do so). Thus, it would be nice if those protocols
could easily access the congestion state such that congestion notification
bits can be set efficiently. 


      [...]

Seems there are lots of interesting problems to investigate and
to solve. Anyhow, no matter how the details will be in future,
What´s basically needed is a return value for netif_rx(). This is also
`nice` for symmetry reasons (in 2.4.x, dev_queue_xmit() returns an
int, too).

Would it possibe to make the return sematics of the varios
layer-boundary-crossing methods conssitent ore are they just to
different? There is currently no agreement among the different
protocol implementations. Many of them use a boolean return value for
reporting whether delivering to upper/lower layer was sucessful.
But there is unfortunatly no unique convention whether 1 means success
or failure.

I´ll be leaving for Linux-Kongress. Thus, I won´t be able to
further contribute to this thread for this week.

Cheers,

Henner

From owner-netdev@oss.sgi.com Tue Sep 19 16:55:15 2000
Received:  by oss.sgi.com id <S42330AbQISXzF>;
	Tue, 19 Sep 2000 16:55:05 -0700
Received: from battlejitney.wdhq.scyld.com ([216.254.93.178]:30710 "EHLO
        vaio.greennet") by oss.sgi.com with ESMTP id <S42234AbQISXyp>;
	Tue, 19 Sep 2000 16:54:45 -0700
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id TAA12324;
	Tue, 19 Sep 2000 19:55:49 -0400
Date:   Tue, 19 Sep 2000 19:55:49 -0400 (EDT)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     Andrew Morton <andrewm@uow.edu.au>
cc:     Jeff Garzik <jgarzik@mandrakesoft.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        netdev@oss.sgi.com, "David S. Miller" <davem@redhat.com>,
        jes@linuxcare.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
In-Reply-To: <39C75CB6.E86C55F@uow.edu.au>
Message-ID: <Pine.LNX.4.10.10009191949100.1031-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 Sep 2000, Andrew Morton wrote:

> > This patch, against 2.4.0-test9-pre2, moves ethtool.h from the private
> > domain of the sparc ports into include/linux.  This publishes an
...
> This is good. It would be useful to have this in place ASAP so driver
> authors have something to look at and to work against.

You all know my opinion on this interface: it is bad.

> * I added SUPPORTED_MAC_FLOWCTRL/ADVERTISED_MAC_FLOWCTRL for advertising
> of 802.3x MAC-layer flow control.

There are two elements of this: Rx and Tx flow control.  We might support Rx
flow control, but not generate flow control packets.  Or perhaps the
inverse.

> * There don't seem to be enough port types and transceiver types. 
> 10base2? BNC? 100baseTx/100baseFX?

1Mbps HomePNA? 10Mbps HomePNA?  (Check the control words for the PNA spec.)
Various 802.11?
10Gb Ethernet?  Have you looked at gigabit autonegotiation?

If you are proposing a new interface (and obviously tossing the
existing MII-MDIO emulation that has existed for a few years) you should at
least support current hardware.


Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf-II Cluster Distribution
Annapolis MD 21403


From owner-netdev@oss.sgi.com Tue Sep 19 17:47:26 2000
Received:  by oss.sgi.com id <S42343AbQITArQ>;
	Tue, 19 Sep 2000 17:47:16 -0700
Received: from laurin.munich.netsurf.de ([194.64.166.1]:19386 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S42234AbQITAqu>; Tue, 19 Sep 2000 17:46:50 -0700
Received: from fred.muc.de (noidentity@ns1058.munich.netsurf.de [195.180.235.58])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id CAA11577;
	Wed, 20 Sep 2000 02:46:47 +0200 (MET DST)
Received: by fred.muc.de (Postfix, from userid 500)
	id 17DFAE3914; Wed, 20 Sep 2000 02:43:19 +0200 (CEST)
Date:   Wed, 20 Sep 2000 02:43:19 +0200
From:   Andi Kleen <ak@muc.de>
To:     =?iso-8859-1?Q?Ram=F3n_Ag=FCero?= <ramon@tlmat.unican.es>
Cc:     netdev@oss.sgi.com
Subject: Re: Giving priority to messages
Message-ID: <20000920024319.A4744@fred.muc.de>
References: <001801c02224$8fa07ac0$1bba90c1@tlmat.unican.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0.1i
In-Reply-To: <001801c02224$8fa07ac0$1bba90c1@tlmat.unican.es>; from ramon@tlmat.unican.es on Tue, Sep 19, 2000 at 12:34:31PM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, Sep 19, 2000 at 12:34:31PM +0200, Ramón Agüero wrote:
>     Hi all,
> 
>     I'm working within an application which creates packets and sends them. To accomplish this I use the dev_queue_xmit function. At a fist stage, everything runs OK, but I would like also to give priority to these messages, in relation with other messages that the machine creates, so that they don't have to wait.
> 
>     I would be pleased if you could tell me how to assign this priority. I'm working with 2.2.14 kernel.
> 

You can set skb->priority to values between 0 and 15 
(see include/linux/pkt_sched.h)
What actually happens depends on the queueing discipline that is set for
the interface. The default one uses a 3 way pfifo, which maps 6 and 7
to the highest priority queue.

Usually this scheduling does not help much though, because the underlying
devices have a longer queue itself where the priorities are ignored
(e.g. bus mastering ethernet cards with big TX rings or worse a modem
that does v.42bis) 

-Andi

-- 
This is like TV. I don't like TV.

From owner-netdev@oss.sgi.com Tue Sep 19 19:06:16 2000
Received:  by oss.sgi.com id <S42297AbQITCF4>;
	Tue, 19 Sep 2000 19:05:56 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:40613 "EHLO cyberus.ca") convert rfc822-to-8bit
	by oss.sgi.com with ESMTP id <S42234AbQITCFb>;
	Tue, 19 Sep 2000 19:05:31 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id WAA10508;
	Tue, 19 Sep 2000 22:05:24 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id WAA05909;
	Tue, 19 Sep 2000 22:05:25 -0400 (EDT)
Date:   Tue, 19 Sep 2000 22:05:23 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Henner Eisen <eis@baty.hanse.de>
cc:     davem@redhat.com, kuznet@ms2.inr.ac.ru, Robert.Olsson@data.slu.se,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com, becker@scyld.com
Subject: Re: [PATCH/RFC] (long) network interface changes
In-Reply-To: <200009192215.AAA17587@baty.hanse.de>
Message-ID: <Pine.GSO.4.20.0009192133350.5716-100000@shell.cyberus.ca>
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 Wed, 20 Sep 2000, Henner Eisen wrote:

[some suggestions for the next re-incarnation of the doc deleted]

>  
>      jamal> I have experimented with two schemes: one which samples the
>     jamal> queue via a timer and one which does it per-packet and
>     jamal> found that the per-packet sampler gave better results (more
>     jamal> samples, Shannon's theorem applies).  It didnt matter
>     jamal> whether HZ was 100 or 1024 during the tests.  The measure
>     jamal> of "better" was throughput.
> 
> Nice. I think such a kind of fair input queueing would be an important
> features because that allows to offer a highly reliable netif() to
> slow links which are slow, but inefficient to handle congestion
> (like X.25 LAPB datalink protocol). Network interfaces could trade
> reliablilty for speed.
> 

So i would prefer to leave this turned off. Infact i was hoping to take it
off for the final code submission. If you insist, it could be left there
and enabled during compile. There could be better ways to do it but
experimentation is required.
It will definetely help in the case of low and high speed devices.

> Another issue: Some protocols designed for congestable links support
> forward and/or backward congestion notification (e.g. frame relay, I thing
> DECnet and IPV6 also can do so). Thus, it would be nice if those protocols
> could easily access the congestion state such that congestion notification
> bits can be set efficiently. 

IPV4 as well. In the case of V6 and V4 it is called ECN. causing
quiet a bit of havoc right now ;->
I can see the netif_rx() feedback clearly fitting in the 'receive
busy/not-ready' details you talked about earlier. I dont see the CN fit
clearly.
Maybe one way is to set the Frame Relay FECN bit after you return from
netif_rx()? callbacks? nah, too complicated...

> Seems there are lots of interesting problems to investigate and
> to solve. Anyhow, no matter how the details will be in future,
> What´s basically needed is a return value for netif_rx(). This is also
> `nice` for symmetry reasons (in 2.4.x, dev_queue_xmit() returns an
> int, too).
> 

Good idea.
There is some mapping e.g.

NET_RX_SUCCESS maps to BLG_CNG_NONE
NET_RX_DROP maps to BLG_CNG_DROP

NET_*_POLICED and NET_*_BYPASS have no proper mapping in the receive
path but we could define them as well

Only difference i see are that we will need several NET_RX_CN defines
because we have BLG_CNG_LOW, BLG_CNG_MOD and BLG_CNG_HIGH
so a NET_RX_CN_LOW, NET_RX_CN_MOD and NET_RX_CN_HIGH would complete it.

> Would it possibe to make the return sematics of the varios
> layer-boundary-crossing methods conssitent ore are they just to
> different? 

Doesnt sound like a bad idea. Maybe Davem and/or Alexey and/or Andi can
comment.

> There is currently no agreement among the different
> protocol implementations. Many of them use a boolean return value for
> reporting whether delivering to upper/lower layer was sucessful.
> But there is unfortunatly no unique convention whether 1 means success
> or failure.

I think the initial idea with the transmit path (not sure how alive the
idea is) was to propagate the return codes from the link layer all the way
to the protocol layer. For example it would help TCP to know of 
NET_TXMIT_DROP to maybe doing something smarter than go into a FR or an
RTO. 

> 
> I´ll be leaving for Linux-Kongress. Thus, I won´t be able to
> further contribute to this thread for this week.

What kind of Linux conference gives you no access to the internet? ;->

cheers,
jamal


From owner-netdev@oss.sgi.com Tue Sep 19 19:25:15 2000
Received:  by oss.sgi.com id <S42344AbQITCY4>;
	Tue, 19 Sep 2000 19:24:56 -0700
Received: from battlejitney.wdhq.scyld.com ([216.254.93.178]:15353 "EHLO
        vaio.greennet") by oss.sgi.com with ESMTP id <S42234AbQITCYY>;
	Tue, 19 Sep 2000 19:24:24 -0700
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id WAA13219;
	Tue, 19 Sep 2000 22:25:36 -0400
Date:   Tue, 19 Sep 2000 22:25:36 -0400 (EDT)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     Andi Kleen <ak@muc.de>
cc:     =?iso-8859-1?Q?Ram=F3n_Ag=FCero?= <ramon@tlmat.unican.es>,
        netdev@oss.sgi.com
Subject: Re: Giving priority to messages
In-Reply-To: <20000920024319.A4744@fred.muc.de>
Message-ID: <Pine.LNX.4.10.10009192217060.1031-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 Wed, 20 Sep 2000, Andi Kleen wrote:

> You can set skb->priority to values between 0 and 15 
> (see include/linux/pkt_sched.h)
> What actually happens depends on the queueing discipline that is set for
> the interface. The default one uses a 3 way pfifo, which maps 6 and 7
> to the highest priority queue.
> 
> Usually this scheduling does not help much though, because the underlying
> devices have a longer queue itself where the priorities are ignored
> (e.g. bus mastering ethernet cards with big TX rings or worse a modem
> that does v.42bis) 

This is one of the reasons for drivers to keep their Tx queues to a
reasonable length.  Two years ago an almost-always-sufficient Tx queue
length was between 6 and 10, so most of my bus-master drivers use a queue
length of 10.  Ten 1500 byte packets at 10Mbps is still not too long, but
ten 60 byte packets (approx. 96 byte periods on the wire) isn't very long at
100Mbps.

If you care *that* *much* about priority and scheduling, you are probably
wrong about what you want.  We did some work on utilizing the real-time
transmit scheduling in the 3Com hardware, and found out that it made almost
zero difference to [[the multimedia application we were testing]].

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf-II Cluster Distribution
Annapolis MD 21403


From owner-netdev@oss.sgi.com Tue Sep 19 19:35:16 2000
Received:  by oss.sgi.com id <S42345AbQITCe4>;
	Tue, 19 Sep 2000 19:34:56 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:48815 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42234AbQITCey>;
	Tue, 19 Sep 2000 19:34:54 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id WAA20518;
	Tue, 19 Sep 2000 22:34:53 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id WAA06000;
	Tue, 19 Sep 2000 22:34:54 -0400 (EDT)
Date:   Tue, 19 Sep 2000 22:34:54 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Donald Becker <becker@scyld.com>
cc:     Andi Kleen <ak@muc.de>,
        =?iso-8859-1?Q?Ram=F3n_Ag=FCero?= <ramon@tlmat.unican.es>,
        netdev@oss.sgi.com
Subject: Re: Giving priority to messages
In-Reply-To: <Pine.LNX.4.10.10009192217060.1031-100000@vaio.greennet>
Message-ID: <Pine.GSO.4.20.0009192227570.5716-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 Tue, 19 Sep 2000, Donald Becker wrote:

> This is one of the reasons for drivers to keep their Tx queues to a
> reasonable length.  Two years ago an almost-always-sufficient Tx queue
> length was between 6 and 10, so most of my bus-master drivers use a queue
> length of 10.  Ten 1500 byte packets at 10Mbps is still not too long, but
> ten 60 byte packets (approx. 96 byte periods on the wire) isn't very long at
> 100Mbps.
> 
> If you care *that* *much* about priority and scheduling, you are probably
> wrong about what you want.  We did some work on utilizing the real-time
> transmit scheduling in the 3Com hardware, and found out that it made almost
> zero difference to [[the multimedia application we were testing]].

Donald,

The Tulip, for example, can have its DMA buffers stashed in a linked list
instead of a ring structure.
Maybe not the most efficient scheme but could you could play with
priority queueing structures/algorithms for the DMA buffers in this
case and for example stick a higher priority packet to the head of the
queue? I have not implemented any such thing, just thinking out
loudly. 

cheers,
jamal


From owner-netdev@oss.sgi.com Tue Sep 19 19:48:46 2000
Received:  by oss.sgi.com id <S42346AbQITCs0>;
	Tue, 19 Sep 2000 19:48:26 -0700
Received: from panic.ohr.gatech.edu ([130.207.47.194]:47373 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S42234AbQITCsB>;
	Tue, 19 Sep 2000 19:48:01 -0700
Received: from mandrakesoft.com (adsl-77-228-182.atl.bellsouth.net [216.77.228.182])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id WAA04577;
	Tue, 19 Sep 2000 22:46:42 -0400
Message-ID: <39C82510.73C59A02@mandrakesoft.com>
Date:   Tue, 19 Sep 2000 22:46:40 -0400
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     jamal <hadi@cyberus.ca>
CC:     Donald Becker <becker@scyld.com>, Andi Kleen <ak@muc.de>,
        " =?iso-8859-1?Q?Ram=F3n=20Ag=FCero?=" <ramon@tlmat.unican.es>,
        netdev@oss.sgi.com
Subject: Re: Giving priority to messages
References: <Pine.GSO.4.20.0009192227570.5716-100000@shell.cyberus.ca>
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

jamal wrote:
> The Tulip, for example, can have its DMA buffers stashed in a linked list
> instead of a ring structure.
> Maybe not the most efficient scheme but could you could play with
> priority queueing structures/algorithms for the DMA buffers in this
> case and for example stick a higher priority packet to the head of the
> queue? I have not implemented any such thing, just thinking out
> loudly.

Keep thinking about loud...   I was thinking that a linked list would be
more flexible and potentially more optimal, but checking that out is
2.5.x material for me :)

From owner-netdev@oss.sgi.com Tue Sep 19 20:27:06 2000
Received:  by oss.sgi.com id <S42349AbQITD0q>;
	Tue, 19 Sep 2000 20:26:46 -0700
Received: from battlejitney.wdhq.scyld.com ([216.254.93.178]:24570 "EHLO
        vaio.greennet") by oss.sgi.com with ESMTP id <S42234AbQITD0a>;
	Tue, 19 Sep 2000 20:26:30 -0700
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id XAA13445;
	Tue, 19 Sep 2000 23:27:45 -0400
Date:   Tue, 19 Sep 2000 23:27:45 -0400 (EDT)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     jamal <hadi@cyberus.ca>
cc:     Andi Kleen <ak@muc.de>,
        =?iso-8859-1?Q?Ram=F3n_Ag=FCero?= <ramon@tlmat.unican.es>,
        netdev@oss.sgi.com
Subject: Re: Giving priority to messages
In-Reply-To: <Pine.GSO.4.20.0009192227570.5716-100000@shell.cyberus.ca>
Message-ID: <Pine.LNX.4.10.10009192302420.1031-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 Sep 2000, jamal wrote:
> On Tue, 19 Sep 2000, Donald Becker wrote:
> 
> > This is one of the reasons for drivers to keep their Tx queues to a
> > reasonable length.  Two years ago an almost-always-sufficient Tx queue
..
> The Tulip, for example, can have its DMA buffers stashed in a linked list
> instead of a ring structure.

Not if you want to work with different Tulip chip types!
The driver sets up the descriptors as both a ring and a linked list.  That
way it works both with chips that only implement chained mode, and chips
that only work properly in ring mode.

This is documented in a driver note.  *Believe* that note.
That detail was learned from time consuming experience.

> Maybe not the most efficient scheme but could you could play with
> priority queueing structures/algorithms for the DMA buffers in this
> case and for example stick a higher priority packet to the head of the
> queue? I have not implemented any such thing, just thinking out
> loudly. 

This isn't a good idea.
There is no safe way to reorder the list after the descriptors have been
passed to the driver (e.g. ownership flag is set).  The 3Com chips are
unique -- they do provide safe semantics to do this with the real-time
schedule.  But it's ugly and inefficient, and certainly doesn't apply to
other chip types.

Keep in mind that reordering the Tx descriptor queue is only getting to part
of the Tx queue.  You might have a bunch of packets hanging out in the
hardware Tx FIFO (2KB to 8KB long), and there is no way that you can get to
the front of *that* queue on most chips.

There are a few recent chips that implement an explicit high priority queue.
The Starfire has a nice implementation, and has a i82559 adds a second, limited
functionality, high priority command queue.  (The commands for this are
revealed in the overview datasheet that is available from Intel's public web
site.)

(Hmmm, this triggers a memory: I propagated the priority in the old 100VG
driver that I wrote.  Now *that* is a driver that had a big world impact ;-)

Anyway, the big picture is that you are likely thinking about a non-problem.
Getting to the front of the 100 packet long software queue is important.
You should be *really* certain, by simulation and modeling not just
intuition, that your application needs to bypass the driver/hardware queue.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf-II Cluster Distribution
Annapolis MD 21403


From owner-netdev@oss.sgi.com Wed Sep 20 02:30:39 2000
Received:  by oss.sgi.com id <S42342AbQITJaT>;
	Wed, 20 Sep 2000 02:30:19 -0700
Received: from horus.its.uow.edu.au ([130.130.68.25]:60067 "EHLO
        horus.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42234AbQITJ3u>;
	Wed, 20 Sep 2000 02:29:50 -0700
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 UAA19516;
	Wed, 20 Sep 2000 20:29:38 +1100 (EST)
Message-ID: <39C883CF.9FB262FC@uow.edu.au>
Date:   Wed, 20 Sep 2000 20:30:55 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8-pre1 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "howling@the.moon" <havanna_moon@gmx.net>
CC:     netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
References: <39C5D263.8DA31C03@mandrakesoft.com> <39C75CB6.E86C55F@uow.edu.au> <008101c02276$fe4fc5a0$1cac243e@dustin>
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

"howling@the.moon" wrote:
> 
> Routers have a tendency not to announce routes for networks
> that are physically down, i miss that in linux. Mr. Becker
> suggested using libmii was a no-no-never solution (up to a few
> ms lockup of the machine per poll) for this issue. Select as
> you suggest seems ideal.

mm.. I've clocked an mdio_read() at 300 usecs.   Not a thing you'd want
to poll very frequently, particularly as some drivers are racy in this
area, and the consequences of hitting the race could be quite bad.  
spin_lock_bh() is the correct solution for mdio protection, BTW.

Of course, with many devices you simply _have_ to poll.

But if someone is setting up a multi-node HA system or a router, it's
not unreasonable to expect them to fork out the $$$ for a NIC which
generates link status change interrupts, and to be prepared to use
twisted pair.

From owner-netdev@oss.sgi.com Wed Sep 20 02:43:58 2000
Received:  by oss.sgi.com id <S42365AbQITJns>;
	Wed, 20 Sep 2000 02:43:48 -0700
Received: from luna.tlmat.unican.es ([193.144.186.2]:61189 "EHLO
        luna.tlmat.unican.es") by oss.sgi.com with ESMTP id <S42234AbQITJnm>;
	Wed, 20 Sep 2000 02:43:42 -0700
Received: from centauro (lira.tlmat.unican.es [193.144.186.27]) by luna.tlmat.unican.es with SMTP (8.7.6/8.7.1) id LAA04760 for <netdev@oss.sgi.com>; Wed, 20 Sep 2000 11:43:20 +0200 (METDST)
Message-ID: <002801c022e5$6a4a8e20$1bba90c1@tlmat.unican.es>
From:   =?iso-8859-1?B?UmFt824gQWf8ZXJv?= <ramon@tlmat.unican.es>
To:     <netdev@oss.sgi.com>
Subject: IP checksum calculation
Date:   Wed, 20 Sep 2000 11:30:23 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0023_01C022F6.2AAF3AC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
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_0023_01C022F6.2AAF3AC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

    I've developped a module that gets IP_packets, and changes their TOS =
field, then I call the ip_fast_csum in order to change its checksum.

    However, the destin doesn't get any packet. When I capture what I'm =
sending I see that that function always return the same value (oxffef). =
May anybody tell me what I'm doing wrong?.

    Thanks in advance

    Ram=F3n

PD.- Please I wish to be personally CC'ed the answers/comments posted to =
the list in response to my posting


------=_NextPart_000_0023_01C022F6.2AAF3AC0
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.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; I've developped a module that =
gets=20
IP_packets, and changes their TOS field, then I call the ip_fast_csum in =
order=20
to change its checksum.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; However, the destin doesn't get =
any packet.=20
When I capture what I'm sending I see that that function always return =
the same=20
value (oxffef). May anybody tell me what I'm doing wrong?.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Thanks in advance</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Ram=F3n</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>PD.- Please&nbsp;I wish to be personally CC'ed the=20
answers/comments posted to the list in response to&nbsp;my=20
posting<BR></DIV></FONT></FONT></DIV></BODY></HTML>

------=_NextPart_000_0023_01C022F6.2AAF3AC0--


From owner-netdev@oss.sgi.com Wed Sep 20 02:49:58 2000
Received:  by oss.sgi.com id <S42394AbQITJts>;
	Wed, 20 Sep 2000 02:49:48 -0700
Received: from pizda.ninka.net ([216.101.162.242]:14222 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42234AbQITJtj>;
	Wed, 20 Sep 2000 02:49:39 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id CAA16092;
	Wed, 20 Sep 2000 02:35:08 -0700
Date:   Wed, 20 Sep 2000 02:35:08 -0700
Message-Id: <200009200935.CAA16092@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     ramon@tlmat.unican.es
CC:     netdev@oss.sgi.com
In-reply-to: <002801c022e5$6a4a8e20$1bba90c1@tlmat.unican.es> (message from
	=?ISO-8859-1?Q?Ram=F3n?= =?ISO-8859-1?Q?Ag=FCero?= on Wed, 20 Sep 2000 11:30:23 +0200)
Subject: Re: IP checksum calculation
References:  <002801c022e5$6a4a8e20$1bba90c1@tlmat.unican.es>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Set the checksum field in the IP header to zero before computing
the new checksum.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Wed Sep 20 02:52:28 2000
Received:  by oss.sgi.com id <S42398AbQITJwT>;
	Wed, 20 Sep 2000 02:52:19 -0700
Received: from luna.tlmat.unican.es ([193.144.186.2]:62725 "EHLO
        luna.tlmat.unican.es") by oss.sgi.com with ESMTP id <S42234AbQITJwO>;
	Wed, 20 Sep 2000 02:52:14 -0700
Received: from centauro (lira.tlmat.unican.es [193.144.186.27]) by luna.tlmat.unican.es with SMTP (8.7.6/8.7.1) id MAA04834 for <netdev@oss.sgi.com>; Wed, 20 Sep 2000 12:07:44 +0200 (METDST)
Message-ID: <004201c022e8$d00c54c0$1bba90c1@tlmat.unican.es>
From:   =?iso-8859-1?B?UmFt824gQWf8ZXJv?= <ramon@tlmat.unican.es>
To:     <netdev@oss.sgi.com>
Subject: IP  checksum calculation
Date:   Wed, 20 Sep 2000 11:54:48 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_003F_01C022F9.9362CA20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
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_003F_01C022F9.9362CA20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

    I've developped a module that gets IP_packets, and changes their TOS =
field, then I call the ip_fast_csum in order to change its checksum.

    However, the destin doesn't get any packet. When I capture what I'm =
sending I see that that function always return the same value (oxffef). =
May anybody tell me what I'm doing wrong?.

    Thanks in advance

    Ram=F3n

PD.- Please I wish to be personally CC'ed the answers/comments posted to =
the list in response to my posting


------=_NextPart_000_003F_01C022F9.9362CA20
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.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; I've developped a module that =
gets=20
IP_packets, and changes their TOS field, then I call the ip_fast_csum in =
order=20
to change its checksum.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; However, the destin doesn't get =
any packet.=20
When I capture what I'm sending I see that that function always return =
the same=20
value (oxffef). May anybody tell me what I'm doing wrong?.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Thanks in advance</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Ram=F3n</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>PD.- Please&nbsp;I wish to be personally CC'ed the=20
answers/comments posted to the list in response to&nbsp;my=20
posting<BR></DIV></FONT></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_003F_01C022F9.9362CA20--


From owner-netdev@oss.sgi.com Wed Sep 20 02:55:19 2000
Received:  by oss.sgi.com id <S42402AbQITJzJ>;
	Wed, 20 Sep 2000 02:55:09 -0700
Received: from horus.its.uow.edu.au ([130.130.68.25]:31413 "EHLO
        horus.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42234AbQITJy6>;
	Wed, 20 Sep 2000 02:54:58 -0700
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 UAA21906;
	Wed, 20 Sep 2000 20:54:32 +1100 (EST)
Message-ID: <39C889A4.CEA8804@uow.edu.au>
Date:   Wed, 20 Sep 2000 20:55:48 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8-pre1 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Donald Becker <becker@scyld.com>
CC:     Jeff Garzik <jgarzik@mandrakesoft.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        netdev@oss.sgi.com, "David S. Miller" <davem@redhat.com>,
        jes@linuxcare.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
References: <39C75CB6.E86C55F@uow.edu.au> <Pine.LNX.4.10.10009191949100.1031-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 Sep 2000, Andrew Morton wrote:
> 
> > > This patch, against 2.4.0-test9-pre2, moves ethtool.h from the private
> > > domain of the sparc ports into include/linux.  This publishes an
> ...
> > This is good. It would be useful to have this in place ASAP so driver
> > authors have something to look at and to work against.
> 
> You all know my opinion on this interface: it is bad.

Yes and no.  I assume you refer to the ability to force link speed,
duplex, etc?  This is a broken way to fix broken hardware/software and I
wouldn't expect many drivers to implement this part.

But the ability to talk to the driver directly, to have a uniform
interface to query the link state, the link settings, to be able to tune
driver-specific settings, to fetch driver-specific performance data and
to dynamically change the driver debug level would be pretty useful.

> > * There don't seem to be enough port types and transceiver types.
> > 10base2? BNC? 100baseTx/100baseFX?
> 
> 1Mbps HomePNA? 10Mbps HomePNA?  (Check the control words for the PNA spec.)
> Various 802.11?
> 10Gb Ethernet?  Have you looked at gigabit autonegotiation?

Not at all, and I suspect that an attempt to define all this stuff
up-front will come unstuck.

> If you are proposing a new interface (and obviously tossing the
> existing MII-MDIO emulation that has existed for a few years) you should at
> least support current hardware.

Well, if the driver supports SIOCGMIIPHY then the userland support
library should be able to sort these things out.  As far as reporting on
interface settings, I'd view this proposal as allowing individual
drivers to fill in any gaps.  But the proposal goes further than this.


Anyway.  Jeff, this smells to me like 2.5-food.  This interface won't be
proven and stabilised until a couple of dissimilar drivers have actually
used it, and the userland stuff is implemented.

From owner-netdev@oss.sgi.com Wed Sep 20 09:05:13 2000
Received:  by oss.sgi.com id <S42425AbQITQFD>;
	Wed, 20 Sep 2000 09:05:03 -0700
Received: from adsl-151-196-249-101.bellatlantic.net ([151.196.249.101]:41465
        "EHLO vaio.greennet") by oss.sgi.com with ESMTP id <S42234AbQITQEi>;
	Wed, 20 Sep 2000 09:04:38 -0700
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id MAA14741;
	Wed, 20 Sep 2000 12:05:50 -0400
Date:   Wed, 20 Sep 2000 12:05:50 -0400 (EDT)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     Andrew Morton <andrewm@uow.edu.au>
cc:     "howling@the.moon" <havanna_moon@gmx.net>, netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
In-Reply-To: <39C883CF.9FB262FC@uow.edu.au>
Message-ID: <Pine.LNX.4.10.10009201152510.1031-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 Wed, 20 Sep 2000, Andrew Morton wrote:

> "howling@the.moon" wrote:
> > 
> > Routers have a tendency not to announce routes for networks
> > that are physically down, i miss that in linux. Mr. Becker
> > suggested using libmii was a no-no-never solution (up to a few
> > ms lockup of the machine per poll) for this issue. Select as
> > you suggest seems ideal.
> 
> mm.. I've clocked an mdio_read() at 300 usecs.

Yup, reading a bunch of MII registers isn't something we want to do without
a good reason.  Some have suggested /proc/bus/mii/eth0, where all 32 MII
registers could be read at once.  This has semantic problems with the
"sticky bits", and it could take 300*32 usec.  Try reading that once per
timer tick ;->

It's much more reasonable to have the driver do this on a 1/3/5/10 second
periodic check (a low-rate poll).

[[ Note: The typical case shouldn't take 300 usec, but on a busy PCI bus
without MII preamble supression, it might take even longer to read a
register. ]]

>   Not a thing you'd want
> to poll very frequently, particularly as some drivers are racy in this
> area, and the consequences of hitting the race could be quite bad.  
> spin_lock_bh() is the correct solution for mdio protection, BTW.

Or having the timer based media monitor just skip the check until the next
tick if the lock is set.  Imagine taking timer interrupt during the
user-level ioctl()...  (There are a few other dangerous cases to consider as
well.) 



Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf-II Cluster Distribution
Annapolis MD 21403


From owner-netdev@oss.sgi.com Wed Sep 20 09:12:43 2000
Received:  by oss.sgi.com id <S42426AbQITQMd>;
	Wed, 20 Sep 2000 09:12:33 -0700
Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:32222 "EHLO
        vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP
	id <S42234AbQITQM3>; Wed, 20 Sep 2000 09:12:29 -0700
Received: (from rgooch@localhost)
	by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e8KGC6x14517;
	Wed, 20 Sep 2000 10:12:06 -0600
Date:   Wed, 20 Sep 2000 10:12:06 -0600
Message-Id: <200009201612.e8KGC6x14517@vindaloo.ras.ucalgary.ca>
From:   Richard Gooch <rgooch@ras.ucalgary.ca>
To:     Andrew Morton <andrewm@uow.edu.au>
Cc:     "howling@the.moon" <havanna_moon@gmx.net>, netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
In-Reply-To: <39C883CF.9FB262FC@uow.edu.au>
References: <39C5D263.8DA31C03@mandrakesoft.com>
	<39C75CB6.E86C55F@uow.edu.au>
	<008101c02276$fe4fc5a0$1cac243e@dustin>
	<39C883CF.9FB262FC@uow.edu.au>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Andrew Morton writes:
> But if someone is setting up a multi-node HA system or a router,
> it's not unreasonable to expect them to fork out the $$$ for a NIC
> which generates link status change interrupts, and to be prepared to
> use twisted pair.

Such as the 3c59x?

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

From owner-netdev@oss.sgi.com Wed Sep 20 20:05:59 2000
Received:  by oss.sgi.com id <S42428AbQIUDFj>;
	Wed, 20 Sep 2000 20:05:39 -0700
Received: from panic.ohr.gatech.edu ([130.207.47.194]:13585 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S42315AbQIUDFJ>;
	Wed, 20 Sep 2000 20:05:09 -0700
Received: from mandrakesoft.com (adsl-77-228-182.atl.bellsouth.net [216.77.228.182])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id XAA20258;
	Wed, 20 Sep 2000 23:04:52 -0400
Message-ID: <39C97AD2.14D57EA3@mandrakesoft.com>
Date:   Wed, 20 Sep 2000 23:04:50 -0400
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
CC:     netdev@oss.sgi.com
Subject: dev->hard_start_xmit return val handling correct?
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
Content-Length: 643
Lines: 18

When dev->hard_start_xmit returns an error, it doesn't seem like
returning ENETDOWN is the best course of action..  Is this correct?

int dev_queue_xmit(struct sk_buff *skb)
[...]
               if (dev->hard_start_xmit(skb, dev) == 0) {
                       dev->xmit_lock_owner = -1;
                       spin_unlock_bh(&dev->xmit_lock);
                       return 0;
               }
       }
       dev->xmit_lock_owner = -1;
       spin_unlock_bh(&dev->xmit_lock);
       if (net_ratelimit())
               printk(KERN_DEBUG "Virtual device %s asks to queue
packet!\n", dev->name);
       kfree_skb(skb);
       return -ENETDOWN;

From owner-netdev@oss.sgi.com Thu Sep 21 04:29:42 2000
Received:  by oss.sgi.com id <S42353AbQIUL3N>;
	Thu, 21 Sep 2000 04:29:13 -0700
Received: from isis.its.uow.edu.au ([130.130.68.21]:5288 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42236AbQIUL2o>;
	Thu, 21 Sep 2000 04:28:44 -0700
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 WAA11569;
	Thu, 21 Sep 2000 22:28:22 +1100 (EST)
Message-ID: <39C9F123.D8FA4F68@uow.edu.au>
Date:   Thu, 21 Sep 2000 22:29:39 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8-pre1 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Donald Becker <becker@scyld.com>
CC:     "howling@the.moon" <havanna_moon@gmx.net>, netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
References: <39C883CF.9FB262FC@uow.edu.au> <Pine.LNX.4.10.10009201152510.1031-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
Content-Length: 644
Lines: 15

Donald Becker wrote:
> 
> ...
> >   Not a thing you'd want
> > to poll very frequently, particularly as some drivers are racy in this
> > area, and the consequences of hitting the race could be quite bad.
> > spin_lock_bh() is the correct solution for mdio protection, BTW.
> 
> Or having the timer based media monitor just skip the check until the next
> tick if the lock is set.  Imagine taking timer interrupt during the
> user-level ioctl()...  (There are a few other dangerous cases to consider as
> well.)

Yes.  On 2.4 (at least) there is nothing to prevent the driver's ioctl()
function from running on two or more CPUs simultaneously.

From owner-netdev@oss.sgi.com Thu Sep 21 04:34:03 2000
Received:  by oss.sgi.com id <S42433AbQIULdw>;
	Thu, 21 Sep 2000 04:33:52 -0700
Received: from colin.muc.de ([193.149.48.1]:18446 "HELO colin.muc.de")
	by oss.sgi.com with SMTP id <S42236AbQIULdi>;
	Thu, 21 Sep 2000 04:33:38 -0700
Received: by colin.muc.de id <140587-2>; Thu, 21 Sep 2000 13:33:03 +0200
Message-ID: <20000921133302.36264@colin.muc.de>
From:   Andi Kleen <ak@muc.de>
To:     Andrew Morton <andrewm@uow.edu.au>
Cc:     Donald Becker <becker@scyld.com>,
        "howling@the.moon" <havanna_moon@gmx.net>, netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
References: <39C883CF.9FB262FC@uow.edu.au> <Pine.LNX.4.10.10009201152510.1031-100000@vaio.greennet> <39C9F123.D8FA4F68@uow.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88e
In-Reply-To: <39C9F123.D8FA4F68@uow.edu.au>; from Andrew Morton on Thu, Sep 21, 2000 at 01:30:42PM +0200
Date:   Thu, 21 Sep 2000 13:33:02 +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1115
Lines: 35

On Thu, Sep 21, 2000 at 01:30:42PM +0200, Andrew Morton wrote:
> Donald Becker wrote:
> > 
> > ...
> > >   Not a thing you'd want
> > > to poll very frequently, particularly as some drivers are racy in this
> > > area, and the consequences of hitting the race could be quite bad.
> > > spin_lock_bh() is the correct solution for mdio protection, BTW.
> > 
> > Or having the timer based media monitor just skip the check until the next
> > tick if the lock is set.  Imagine taking timer interrupt during the
> > user-level ioctl()...  (There are a few other dangerous cases to consider as
> > well.)
> 
> Yes.  On 2.4 (at least) there is nothing to prevent the driver's ioctl()
> function from running on two or more CPUs simultaneously.

There is (2.4.0test9pre2): 

asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
{
        struct file * filp;
        unsigned int flag;
        int on, error = -EBADF;

        filp = fget(fd);
        if (!filp)
                goto out;
        error = 0;
        lock_kernel();                   <--------------
        switch (cmd) {



-Andi

From owner-netdev@oss.sgi.com Thu Sep 21 04:36:03 2000
Received:  by oss.sgi.com id <S42356AbQIULfx>;
	Thu, 21 Sep 2000 04:35:53 -0700
Received: from isis.its.uow.edu.au ([130.130.68.21]:34987 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42236AbQIULfm>;
	Thu, 21 Sep 2000 04:35:42 -0700
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 WAA12029;
	Thu, 21 Sep 2000 22:32:50 +1100 (EST)
Message-ID: <39C9F22F.E57BF151@uow.edu.au>
Date:   Thu, 21 Sep 2000 22:34:07 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8-pre1 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Richard Gooch <rgooch@ras.ucalgary.ca>
CC:     "howling@the.moon" <havanna_moon@gmx.net>, netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
References: <39C883CF.9FB262FC@uow.edu.au>,
		<39C5D263.8DA31C03@mandrakesoft.com>
		<39C75CB6.E86C55F@uow.edu.au>
		<008101c02276$fe4fc5a0$1cac243e@dustin>
		<39C883CF.9FB262FC@uow.edu.au> <200009201612.e8KGC6x14517@vindaloo.ras.ucalgary.ca>
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
Content-Length: 686
Lines: 18

Richard Gooch wrote:
> 
> Andrew Morton writes:
> > But if someone is setting up a multi-node HA system or a router,
> > it's not unreasonable to expect them to fork out the $$$ for a NIC
> > which generates link status change interrupts, and to be prepared to
> > use twisted pair.
> 
> Such as the 3c59x?

Yep. 3c905B. 905C and most of the Cardbus NICs.

I don't know how useful the whole link-state-change-interrupt thing is
in practice.  The HA guys would, I suspect, say "thanks very much" and
continue to use application-level heartbeating, as they should.

We (I) need to ask them, and verify that there is actually a use for
this interface before running away and coding stuff.

From owner-netdev@oss.sgi.com Thu Sep 21 04:56:53 2000
Received:  by oss.sgi.com id <S42434AbQIUL4d>;
	Thu, 21 Sep 2000 04:56:33 -0700
Received: from isis.its.uow.edu.au ([130.130.68.21]:9148 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42236AbQIUL4L>;
	Thu, 21 Sep 2000 04:56:11 -0700
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 WAA14827;
	Thu, 21 Sep 2000 22:55:53 +1100 (EST)
Message-ID: <39C9F797.1F9057F4@uow.edu.au>
Date:   Thu, 21 Sep 2000 22:57:11 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8-pre1 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andi Kleen <ak@muc.de>
CC:     Donald Becker <becker@scyld.com>,
        "howling@the.moon" <havanna_moon@gmx.net>, netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
References: <39C883CF.9FB262FC@uow.edu.au> <Pine.LNX.4.10.10009201152510.1031-100000@vaio.greennet> <39C9F123.D8FA4F68@uow.edu.au>,
		<39C9F123.D8FA4F68@uow.edu.au>; from Andrew Morton on Thu, Sep 21, 2000 at 01:30:42PM +0200 <20000921133302.36264@colin.muc.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
Content-Length: 936
Lines: 36

Hi, Andi.

Andi Kleen wrote:
> 
> ..
> > Yes.  On 2.4 (at least) there is nothing to prevent the driver's ioctl()
> > function from running on two or more CPUs simultaneously.
> 
> There is (2.4.0test9pre2):
> 
> asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
> {
>         struct file * filp;
>         unsigned int flag;
>         int on, error = -EBADF;
> 
>         filp = fget(fd);
>         if (!filp)
>                 goto out;
>         error = 0;
>         lock_kernel();                   <--------------
>         switch (cmd) {
> 

But sys_ioctl calls....

int sock_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
            unsigned long arg)
{
        struct socket *sock;
        int err;

        unlock_kernel();                   <---------------
        sock = socki_lookup(inode);
        sock = socki_lookup(inode);
        err = sock->ops->ioctl(sock, cmd, arg);

From owner-netdev@oss.sgi.com Thu Sep 21 05:13:23 2000
Received:  by oss.sgi.com id <S42435AbQIUMND>;
	Thu, 21 Sep 2000 05:13:03 -0700
Received: from pizda.ninka.net ([216.101.162.242]:2432 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42236AbQIUMMd>;
	Thu, 21 Sep 2000 05:12:33 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id EAA09358;
	Thu, 21 Sep 2000 04:59:54 -0700
Date:   Thu, 21 Sep 2000 04:59:54 -0700
Message-Id: <200009211159.EAA09358@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     ak@muc.de
CC:     andrewm@uow.edu.au, becker@scyld.com, havanna_moon@gmx.net,
        netdev@oss.sgi.com
In-reply-to: <20000921133302.36264@colin.muc.de> (message from Andi Kleen on
	Thu, 21 Sep 2000 13:33:02 +0200)
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
References: <39C883CF.9FB262FC@uow.edu.au> <Pine.LNX.4.10.10009201152510.1031-100000@vaio.greennet> <39C9F123.D8FA4F68@uow.edu.au> <20000921133302.36264@colin.muc.de>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 214
Lines: 11

   From: Andi Kleen <ak@muc.de>
   Date:   Thu, 21 Sep 2000 13:33:02 +0200

   There is (2.4.0test9pre2): 

Andi, mind taking a quick peek at net/socket.c:sock_ioctl() :-)

Later,
David S. Miller
davem@redhat.com


From owner-netdev@oss.sgi.com Thu Sep 21 05:27:52 2000
Received:  by oss.sgi.com id <S42436AbQIUM1n>;
	Thu, 21 Sep 2000 05:27:43 -0700
Received: from laurin.munich.netsurf.de ([194.64.166.1]:14068 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S42236AbQIUM12>; Thu, 21 Sep 2000 05:27:28 -0700
Received: from fred.muc.de (noidentity@ns1070.munich.netsurf.de [195.180.235.70])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id OAA26427;
	Thu, 21 Sep 2000 14:27:12 +0200 (MET DST)
Received: by fred.muc.de (Postfix, from userid 500)
	id 161C0E3913; Thu, 21 Sep 2000 14:30:42 +0200 (CEST)
Date:   Thu, 21 Sep 2000 14:30:42 +0200
From:   Andi Kleen <ak@muc.de>
To:     "David S. Miller" <davem@redhat.com>
Cc:     ak@muc.de, andrewm@uow.edu.au, becker@scyld.com,
        havanna_moon@gmx.net, netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
Message-ID: <20000921143042.A3635@fred.muc.de>
References: <39C883CF.9FB262FC@uow.edu.au> <Pine.LNX.4.10.10009201152510.1031-100000@vaio.greennet> <39C9F123.D8FA4F68@uow.edu.au> <20000921133302.36264@colin.muc.de> <200009211159.EAA09358@pizda.ninka.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200009211159.EAA09358@pizda.ninka.net>; from davem@redhat.com on Thu, Sep 21, 2000 at 02:12:25PM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 586
Lines: 21

On Thu, Sep 21, 2000 at 02:12:25PM +0200, David S. Miller wrote:
>    From: Andi Kleen <ak@muc.de>
>    Date:   Thu, 21 Sep 2000 13:33:02 +0200
> 
>    There is (2.4.0test9pre2): 
> 
> Andi, mind taking a quick peek at net/socket.c:sock_ioctl() :-)

I hadn't expected such stupid code to survive in 2.4 @)

Looks rather wastefull. How about adding a inode or file flag for that ? 

Also I would propose to run dev->do_ioctl and probably other device
methods inside the BKL, they are not performance critical anyways and 
it is much safer.


-Andi

-- 
This is like TV. I don't like TV.

From owner-netdev@oss.sgi.com Thu Sep 21 05:36:23 2000
Received:  by oss.sgi.com id <S42440AbQIUMgD>;
	Thu, 21 Sep 2000 05:36:03 -0700
Received: from pizda.ninka.net ([216.101.162.242]:5504 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42236AbQIUMgC>;
	Thu, 21 Sep 2000 05:36:02 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id FAA11621;
	Thu, 21 Sep 2000 05:23:25 -0700
Date:   Thu, 21 Sep 2000 05:23:25 -0700
Message-Id: <200009211223.FAA11621@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     ak@muc.de
CC:     andrewm@uow.edu.au, becker@scyld.com, havanna_moon@gmx.net,
        netdev@oss.sgi.com
In-reply-to: <20000921143042.A3635@fred.muc.de> (message from Andi Kleen on
	Thu, 21 Sep 2000 14:30:42 +0200)
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
References: <39C883CF.9FB262FC@uow.edu.au> <Pine.LNX.4.10.10009201152510.1031-100000@vaio.greennet> <39C9F123.D8FA4F68@uow.edu.au> <20000921133302.36264@colin.muc.de> <200009211159.EAA09358@pizda.ninka.net> <20000921143042.A3635@fred.muc.de>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 640
Lines: 21

   Date: Thu, 21 Sep 2000 14:30:42 +0200
   From: Andi Kleen <ak@muc.de>

   Also I would propose to run dev->do_ioctl and probably other device
   methods inside the BKL, they are not performance critical anyways
   and it is much safer.

Why, that's really dumb.

All of net/* and drivers/net/* runs %100 asynchronous and threaded on
SMP systems.  Your suggested change would create a new exception :-)

The only exception being "stupid" protocols which are:

1) wrapped by a global spinlock in softint processing
2) wrapped with lock_kernel()/unlock_kernel() around socket method
   entry points

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Thu Sep 21 06:20:43 2000
Received:  by oss.sgi.com id <S42432AbQIUNUX>;
	Thu, 21 Sep 2000 06:20:23 -0700
Received: from leonardo.telscom.ch ([193.247.121.34]:62986 "EHLO
        leonardo.telscom.ch") by oss.sgi.com with ESMTP id <S42236AbQIUNUI>;
	Thu, 21 Sep 2000 06:20:08 -0700
Received: from swetha ([193.247.121.46]) by leonardo.telscom.ch
          (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-0U10L2S100)
          with SMTP id AAA106 for <netdev@oss.sgi.com>;
          Thu, 21 Sep 2000 15:11:51 +0200
Message-ID: <014101c023ce$5d3eb640$2e79f7c1@lakshmi>
Reply-To: "Riccardo De Luca" <riccardo@telscom.ch>
From:   "Riccardo De Luca" <Riccardo.DeLuca@telscom.ch>
To:     <netdev@oss.sgi.com>
Subject: Glibc
Date:   Thu, 21 Sep 2000 15:17:49 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_013C_01C023DF.1AB19A20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 3118
Lines: 84

This is a multi-part message in MIME format.

------=_NextPart_000_013C_01C023DF.1AB19A20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Sirs,

I am working on a machine in which it is installed Linux 6.0 with Kernel =
2.2.16 (supports IPv6).
Inside the Ip6.h file located in /usr/include/netinet/ip6.h, there are =
features of the old Standard for IPv6 Header Structure, like, for =
instance, TOS field with 4 bits instead of 8.
I tried to install the latest version of glibc: glibc-2.1.92-5.src.rpm =
in which there are a lot files like /usr/include/netinet/ip6.h  but I =
get an error message.=20
I typed:
=20
#rpm -i glibc-2.1.92-5.src.rpm
"Only packages with major numbers <=3D3 are supported by this version of =
RPM"

So, I downloaded the last version of RPM: rpm-3.0.4-0.48.src.rpm but it =
seems to be not installed because I got the same error.

Would you be so kind to help me to get the new files contained in glibc?
=20
Thank you in advance.
Riccardo

------=_NextPart_000_013C_01C023DF.1AB19A20
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.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dear Sirs,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I am working on&nbsp;a machine in which =
it is=20
installed Linux 6.0 with Kernel 2.2.16 (supports IPv6).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Inside the Ip6.h file located in=20
/usr/include/netinet/ip6.h, there&nbsp;are features of the old Standard =
for IPv6=20
Header Structure, like, for instance, TOS field with 4 bits instead of=20
8.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I tried to install the latest version =
of glibc:=20
<STRONG>glibc-2.1.92-5.src.rpm</STRONG> in which there are a lot =
files&nbsp;like=20
/usr/include/netinet/ip6.h&nbsp; but I get an error message. =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I typed:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>#rpm -i =
glibc-2.1.92-5.src.rpm</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>"Only packages with major numbers =
&lt;=3D3 are=20
supported by this version of RPM"</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3><FONT size=3D2>So, I downloaded the =
last version of=20
RPM</FONT>: rpm-3.0.4-0.48.src.rpm <FONT size=3D2>but it seems to be not =
installed=20
because I got the same error.</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Would you be so kind to help me to get =
the new=20
files contained in glibc</FONT><FONT face=3DArial =
size=3D2>?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you in advance.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Riccardo</FONT></DIV></BODY></HTML>

------=_NextPart_000_013C_01C023DF.1AB19A20--


From owner-netdev@oss.sgi.com Thu Sep 21 06:29:13 2000
Received:  by oss.sgi.com id <S42442AbQIUN2x>;
	Thu, 21 Sep 2000 06:28:53 -0700
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:55044 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S42236AbQIUN2n>; Thu, 21 Sep 2000 06:28:43 -0700
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 WAA10864;
	Thu, 21 Sep 2000 22:28:10 +0900
To:     riccardo@telscom.ch, Riccardo.DeLuca@telscom.ch
Cc:     netdev@oss.sgi.com
Subject: Re: Glibc
In-Reply-To: <014101c023ce$5d3eb640$2e79f7c1@lakshmi>
References: <014101c023ce$5d3eb640$2e79f7c1@lakshmi>
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: <20000921222809J.yoshfuji@ecei.tohoku.ac.jp>
Date:   Thu, 21 Sep 2000 22:28:09 +0900
From:   Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) 
        <yoshfuji@ecei.tohoku.ac.jp>
X-Dispatcher: imput version 990905(IM130)
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 450
Lines: 10

In article <014101c023ce$5d3eb640$2e79f7c1@lakshmi> (at Thu, 21 Sep 2000 15:17:49 +0200), "Riccardo De Luca" <Riccardo.DeLuca@telscom.ch> says:

> Would you be so kind to help me to get the new files contained in glibc?

You could build netinet/ip6.h from RFC2292(bis).

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@v6.linux.or.jp>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Thu Sep 21 06:31:43 2000
Received:  by oss.sgi.com id <S42443AbQIUNbX>;
	Thu, 21 Sep 2000 06:31:23 -0700
Received: from colin.muc.de ([193.149.48.1]:9235 "HELO colin.muc.de")
	by oss.sgi.com with SMTP id <S42236AbQIUNbR>;
	Thu, 21 Sep 2000 06:31:17 -0700
Received: by colin.muc.de id <140591-1>; Thu, 21 Sep 2000 15:31:05 +0200
Message-ID: <20000921153057.04813@colin.muc.de>
From:   Andi Kleen <ak@muc.de>
To:     "David S. Miller" <davem@redhat.com>
Cc:     ak@muc.de, andrewm@uow.edu.au, becker@scyld.com,
        havanna_moon@gmx.net, netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
References: <39C883CF.9FB262FC@uow.edu.au> <Pine.LNX.4.10.10009201152510.1031-100000@vaio.greennet> <39C9F123.D8FA4F68@uow.edu.au> <20000921133302.36264@colin.muc.de> <200009211159.EAA09358@pizda.ninka.net> <20000921143042.A3635@fred.muc.de> <200009211223.FAA11621@pizda.ninka.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88e
In-Reply-To: <200009211223.FAA11621@pizda.ninka.net>; from David S. Miller on Thu, Sep 21, 2000 at 02:35:53PM +0200
Date:   Thu, 21 Sep 2000 15:30:57 +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1472
Lines: 38

On Thu, Sep 21, 2000 at 02:35:53PM +0200, David S. Miller wrote:
>    Date: Thu, 21 Sep 2000 14:30:42 +0200
>    From: Andi Kleen <ak@muc.de>
> 
>    Also I would propose to run dev->do_ioctl and probably other device
>    methods inside the BKL, they are not performance critical anyways
>    and it is much safer.
> 
> Why, that's really dumb.
> 
> All of net/* and drivers/net/* runs %100 asynchronous and threaded on
> SMP systems.  Your suggested change would create a new exception :-)

The difference is that hard_start_xmit et.al. are guaranteed to not reenter
on the same CPU. No such guarantee for the ioctl. I would not be surprised
if lots of them are not reentrant. Of course it could be fixed by adding
a reentrancy lock, but that would be overkill because the BKL does fine
for such things. They usually do also not synchronize against the RX/TX
threads properly (e.g. no hw register lock), that needs to be fixed in the 
drivers, but I think it would be useless to add no-reeentrancy-against-itself
locks in all low level driver ioctls, that is better in higher levels.

Quick grep in drivers/net/* shows several drivers which are unsafe, mostly
by not protecting their data structures or hardware state: 

depca (  while(lp->tx_old != lp->tx_new);    /* Wait for the ring to empty */
looks pretty scary in a ioctl BTW ), 

dgrs

ppp_synctty: calls n_tty_ioctl, which is surely not non BLK safe

even the happy meal ioctls look quite unsafe. 

...


-Andi

From owner-netdev@oss.sgi.com Thu Sep 21 08:48:33 2000
Received:  by oss.sgi.com id <S42190AbQIUPsY>;
	Thu, 21 Sep 2000 08:48:24 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:40199 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42188AbQIUPsK>;
	Thu, 21 Sep 2000 08:48:10 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA01230; Thu, 21 Sep 2000 19:47:38 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200009211547.TAA01230@ms2.inr.ac.ru>
Subject: Re: dev->hard_start_xmit return val handling correct?
To:     jgarzik@mandrakesoft.COM (Jeff Garzik)
Date:   Thu, 21 Sep 2000 19:47:38 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <39C97AD2.14D57EA3@mandrakesoft.com> from "Jeff Garzik" at Sep 21, 0 07:15:00 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 392
Lines: 13

Hello!

> When dev->hard_start_xmit returns an error, it doesn't seem like
> returning ENETDOWN is the best course of action..  Is this correct?

hard_start_xmit never returns errors, unfortunately.

Any non-zero return value means "try again".

It would be not bad idea to check drivers that they always return 1,
when want deferring and to use negative values for errors then. Yes.

Alexey

From owner-netdev@oss.sgi.com Thu Sep 21 12:43:05 2000
Received:  by oss.sgi.com id <S42236AbQIUTmp>;
	Thu, 21 Sep 2000 12:42:45 -0700
Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:28801 "EHLO
        vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP
	id <S42210AbQIUTm2>; Thu, 21 Sep 2000 12:42:28 -0700
Received: (from rgooch@localhost)
	by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e8LJftR02210;
	Thu, 21 Sep 2000 13:41:55 -0600
Date:   Thu, 21 Sep 2000 13:41:55 -0600
Message-Id: <200009211941.e8LJftR02210@vindaloo.ras.ucalgary.ca>
From:   Richard Gooch <rgooch@ras.ucalgary.ca>
To:     Andrew Morton <andrewm@uow.edu.au>
Cc:     "howling@the.moon" <havanna_moon@gmx.net>, netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
In-Reply-To: <39C9F22F.E57BF151@uow.edu.au>
References: <39C883CF.9FB262FC@uow.edu.au>
	<39C5D263.8DA31C03@mandrakesoft.com>
	<39C75CB6.E86C55F@uow.edu.au>
	<008101c02276$fe4fc5a0$1cac243e@dustin>
	<200009201612.e8KGC6x14517@vindaloo.ras.ucalgary.ca>
	<39C9F22F.E57BF151@uow.edu.au>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1044
Lines: 32

Andrew Morton writes:
> Richard Gooch wrote:
> > 
> > Andrew Morton writes:
> > > But if someone is setting up a multi-node HA system or a router,
> > > it's not unreasonable to expect them to fork out the $$$ for a NIC
> > > which generates link status change interrupts, and to be prepared to
> > > use twisted pair.
> > 
> > Such as the 3c59x?
> 
> Yep. 3c905B. 905C and most of the Cardbus NICs.
> 
> I don't know how useful the whole link-state-change-interrupt thing
> is in practice.  The HA guys would, I suspect, say "thanks very
> much" and continue to use application-level heartbeating, as they
> should.

It's not just HA guys. Mobile users can use this too: "oh, the link
died, let's shut down the interface" and "hey, the link is back up,
let's tell bootpclient to ask for a new lease".

> We (I) need to ask them, and verify that there is actually a use for
> this interface before running away and coding stuff.

There is a use.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

From owner-netdev@oss.sgi.com Thu Sep 21 15:10:56 2000
Received:  by oss.sgi.com id <S42210AbQIUWKf>;
	Thu, 21 Sep 2000 15:10:35 -0700
Received: from pizda.ninka.net ([216.101.162.242]:32900 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42208AbQIUWKN>;
	Thu, 21 Sep 2000 15:10:13 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id OAA04002;
	Thu, 21 Sep 2000 14:57:31 -0700
Date:   Thu, 21 Sep 2000 14:57:31 -0700
Message-Id: <200009212157.OAA04002@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     ak@muc.de
CC:     andrewm@uow.edu.au, becker@scyld.com, havanna_moon@gmx.net,
        netdev@oss.sgi.com
In-reply-to: <20000921153057.04813@colin.muc.de> (message from Andi Kleen on
	Thu, 21 Sep 2000 15:30:57 +0200)
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
References: <39C883CF.9FB262FC@uow.edu.au> <Pine.LNX.4.10.10009201152510.1031-100000@vaio.greennet> <39C9F123.D8FA4F68@uow.edu.au> <20000921133302.36264@colin.muc.de> <200009211159.EAA09358@pizda.ninka.net> <20000921143042.A3635@fred.muc.de> <200009211223.FAA11621@pizda.ninka.net> <20000921153057.04813@colin.muc.de>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 404
Lines: 14

   From: Andi Kleen <ak@muc.de>
   Date:   Thu, 21 Sep 2000 15:30:57 +0200

   Quick grep in drivers/net/* shows several drivers which are unsafe,
   mostly by not protecting their data structures or hardware state:

Great work, let's start fixing them, I'll certainly start doing it for
drivers I maintain tonight.  I hope others will soon do the same.

Thanks.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Thu Sep 21 20:02:37 2000
Received:  by oss.sgi.com id <S42248AbQIVDC2>;
	Thu, 21 Sep 2000 20:02:28 -0700
Received: from m201-3-p01.warwick.net ([208.242.201.106]:5124 "EHLO
        circuit.moureaux.com") by oss.sgi.com with ESMTP id <S42188AbQIVDCJ>;
	Thu, 21 Sep 2000 20:02:09 -0700
Received: from localhost (IDENT:statux@localhost [127.0.0.1])
	by circuit.moureaux.com (8.9.3/8.9.3) with ESMTP id XAA01242;
	Thu, 21 Sep 2000 23:02:23 -0400
Date:   Thu, 21 Sep 2000 23:02:23 -0400 (EDT)
From:   Statux <statux@bigfoot.com>
X-Sender: statux@circuit.moureaux.com
To:     Riccardo De Luca <riccardo@telscom.ch>
cc:     netdev@oss.sgi.com
Subject: Re: Glibc
In-Reply-To: <014101c023ce$5d3eb640$2e79f7c1@lakshmi>
Message-ID: <Pine.LNX.4.21.0009212301040.1233-100000@circuit.moureaux.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
Content-Length: 802
Lines: 13

> I am working on a machine in which it is installed Linux 6.0 with Kernel 2.2.16 (supports IPv6).
> Inside the Ip6.h file located in /usr/include/netinet/ip6.h, there are features of the old Standard for IPv6 Header Structure, like, for instance, TOS field with 4 bits instead of 8.
> I tried to install the latest version of glibc: glibc-2.1.92-5.src.rpm in which there are a lot files like /usr/include/netinet/ip6.h  but I get an error message. 
> I typed:
>  
> #rpm -i glibc-2.1.92-5.src.rpm
> "Only packages with major numbers <=3 are supported by this version of RPM"

with source rpms, you have to --rebuild or get the installer
version.. unless you want the source code to it. But you said that you
want to install it, so get either the install rpm or do an rpm --rebuild
on the source rpm.


From owner-netdev@oss.sgi.com Thu Sep 21 20:59:58 2000
Received:  by oss.sgi.com id <S42272AbQIVD7s>;
	Thu, 21 Sep 2000 20:59:48 -0700
Received: from mailo.vtcif.telstra.com.au ([202.12.144.17]:21490 "EHLO
        mailo.vtcif.telstra.com.au") by oss.sgi.com with ESMTP
	id <S42188AbQIVD7f>; Thu, 21 Sep 2000 20:59:35 -0700
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id OAA14170; Fri, 22 Sep 2000 14:59:32 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
 via SMTP by mailo.vtcif.telstra.com.au, id smtpdpG11G_; Fri Sep 22 13:59:01 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id OAA27944; Fri, 22 Sep 2000 14:59:00 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
 via SMTP by localhost, id smtpdcEg5Y_; Fri Sep 22 13:58:20 2000
Received: from vus068.trl.telstra.com.au (vus068.trl.telstra.com.au [137.147.113.21]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA17240; Fri, 22 Sep 2000 14:58:20 +1100 (EST)
Received: from localhost (c729953@localhost)
	by vus068.trl.telstra.com.au (8.9.1b+Sun/8.9.1) with ESMTP id OAA13760;
	Fri, 22 Sep 2000 14:58:18 +1100 (EST)
Date:   Fri, 22 Sep 2000 14:58:18 +1100 (EST)
From:   Roger Venning <c729953@vus068.trl.telstra.com.au>
To:     Andrew Morton <andrewm@uow.edu.au>
cc:     Richard Gooch <rgooch@ras.ucalgary.ca>,
        "howling@the.moon" <havanna_moon@gmx.net>, netdev@oss.sgi.com
Subject: Re: PATCH 2.4.0.9.2: export ethtool interface
In-Reply-To: <39C9F22F.E57BF151@uow.edu.au>
Message-ID: <Pine.GSO.4.21.0009221450140.13603-100000@vus068.trl.telstra.com.au>
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
Content-Length: 1619
Lines: 43


see below...

On Thu, 21 Sep 2000, Andrew Morton wrote:
<snip> 
> Yep. 3c905B. 905C and most of the Cardbus NICs.
> 
> I don't know how useful the whole link-state-change-interrupt thing is
> in practice.  The HA guys would, I suspect, say "thanks very much" and
> continue to use application-level heartbeating, as they should.
> 
> We (I) need to ask them, and verify that there is actually a use for
> this interface before running away and coding stuff.

One use I have in mind is for mobile devices, eg. a laptop that has
multiple network interfaces. There is a protocol called "mobile IP"
(RFC2002) that lets you roam around various points of attachments to
various networks, and keeping the same home IP address via tunnelling
tricks. In order to hand off from one medium to another quickly, eg. wired
lan to wireless, getting hints from lower layers (eg. via the select() on
a socket interface) can assist user mode software in making snappy
handoffs. Many present implementations rely on timeouts for this kind of
thing, encouraging 'beacon' rates within the network to be set higher than
is desirable.

There is Linux software for RFC2002+ support today -
http://www.cs.hut.fi/Research/Dynamics/

Having link layer indications about availability would make performance
much snappier and implementations more elegant.

Roger.


-------------------------------------------------------------------------
Roger Venning \ Do not go gentle into that good night Technologist \ Rage,
rage against the dying of the light. Telstra Research Labs \Dylan Thomas
<r.venning@trl.telstra.com.au> Phone: +61 3 9253 6295






From owner-netdev@oss.sgi.com Fri Sep 22 05:36:03 2000
Received:  by oss.sgi.com id <S42222AbQIVMfx>;
	Fri, 22 Sep 2000 05:35:53 -0700
Received: from isis.its.uow.edu.au ([130.130.68.21]:26533 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42204AbQIVMfj>;
	Fri, 22 Sep 2000 05:35:39 -0700
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 XAA00884;
	Fri, 22 Sep 2000 23:35:11 +1100 (EST)
Message-ID: <39CB524E.2EB250E0@uow.edu.au>
Date:   Fri, 22 Sep 2000 23:36:30 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8-pre1 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     David Fries <dfries@umr.edu>
CC:     vortex@scyld.com, "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: [vortex] can't unload module
References: <20000921002752.A10927@d-131-151-189-65.dynamic.umr.edu>
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
Content-Length: 2593
Lines: 74

[ added netdev ]

David Fries wrote:
> 
> I don't know if it is a motherboard/network card combination, but I
> see networking going down the tube with nfs traffic the first to show
> things slowing down.  Sometimes networking completely stops and
> without any error message.
> 
> In previous kernels I just did ifconfig eth0 down, rmmod 3c59x, insmod
> 3c59x, ifconfig ... and it was back to normal.

This is unfamiliar and it does sound like a driver problem.  Does it do
this under kernel 2.2?

Could you please do some further investigation?  Try increasing the
driver debug level, look at the `ifconfig' output and /proc/interrupts
when it's happening, etc?  Thanks.

> Now I booted the 2.4.0-test9 pre4 kernel ( the test8 did it also, but
> I think I could unload under test7).  This is with a 3c509B network
> card.
> 
> With 2.4.0-test9 it gives me,
> 
> unregister_netdevice: waiting for eth0 to become free.  Usage count =
> 2
> 
> and that keeps scrolling on the screen.

And does it continue to do this for more than thirty seconds?

If so, then someone may be leaking some skbuffs.

Is this an NFS server or a client?

What NFS mount options are you using (specifically, rsize and wsize)?

I've just tried an ifdown/rmmod in the middle of heavy NFS client
traffic and everything seems to hang together, although the application
which is using NFS gets errors when the interface is brought back up.  
(Is NFS client supposed to be able to recover from a local interface
outage??)

Are you able to provide a set of steps with which others can reproduce
this?

Are you running SMP?  I assume not, because if you were, your kernel
would have locked up good and tight.

Alexey, Dave: that wait-for-ever crap which went into
unregister_netdevice() happens under the lock_kernel() in
sys_delete_module()!  This means that the kernel lock will be held until
all the frags expire.  Ugly.  Is sys_delete_module() the only user of
unregister_netdevice who can get bitten by this?

> If I run ifconfig it hangs, doing strace ifconfig shows it hangs on
> the ioctl ( SIOCGIFCONF) call.

Possibly the rtnetlink semaphore. Not sure.

> /proc/net/dev does not list an eth0 device
> /proc/modules lists 3c59x 21992  0 (deleted)

OK, you're not using SMP :)

> I need the latest kernel or usb crashes, but if networking goes down
> I'm SOL, time to reboot which is just as annoying.
> 
> I'm open to suggestions.

David, it would be useful if you could play with this or an hour or so
and characterise it a bit more.  It sounds nicely reproducible, which is
good.  But how do I reproduce it here?

From owner-netdev@oss.sgi.com Fri Sep 22 08:34:44 2000
Received:  by oss.sgi.com id <S42251AbQIVPeY>;
	Fri, 22 Sep 2000 08:34:24 -0700
Received: from isis.its.uow.edu.au ([130.130.68.21]:1436 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42204AbQIVPeK>;
	Fri, 22 Sep 2000 08:34:10 -0700
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 CAA12472
	for <netdev@oss.sgi.com>; Sat, 23 Sep 2000 02:34:03 +1100 (EST)
Message-ID: <39CB7C36.6656B8F2@uow.edu.au>
Date:   Sat, 23 Sep 2000 02:35:21 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8-pre1 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: [vortex] can't unload module
References: <20000921002752.A10927@d-131-151-189-65.dynamic.umr.edu> <39CB524E.2EB250E0@uow.edu.au>
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
Content-Length: 196
Lines: 7

Andrew Morton wrote:
> 
> Alexey, Dave: that wait-for-ever crap which went into
> unregister_netdevice() happens under the lock_kernel() in
> sys_delete_module()!

Duh.  schedule() drops the BKL.

From owner-netdev@oss.sgi.com Fri Sep 22 13:40:14 2000
Received:  by oss.sgi.com id <S42257AbQIVUjz>;
	Fri, 22 Sep 2000 13:39:55 -0700
Received: from mrelay.cc.umr.edu ([131.151.1.89]:21775 "EHLO smtp.umr.edu")
	by oss.sgi.com with ESMTP id <S42217AbQIVUjj>;
	Fri, 22 Sep 2000 13:39:39 -0700
Received: from d-131-151-189-65.dynamic.umr.edu (d-131-151-189-65.dynamic.umr.edu [131.151.189.65]) via ESMTP by mrelay.cc.umr.edu (8.9.3/R.4.20) id PAA20531; Fri, 22 Sep 2000 15:39:37 -0500
Received: (from david@localhost)
	by d-131-151-189-65.dynamic.umr.edu (8.11.0/8.11.0/Debian 8.11.0-1) id e8MKd1Q25063;
	Fri, 22 Sep 2000 15:39:01 -0500
Date:   Fri, 22 Sep 2000 15:39:00 -0500
From:   David Fries <dfries@umr.edu>
To:     Andrew Morton <andrewm@uow.edu.au>
Cc:     vortex@scyld.com, netdev@oss.sgi.com
Subject: Re: [vortex] can't unload module
Message-ID: <20000922153900.A24813@d-131-151-189-65.dynamic.umr.edu>
References: <20000921002752.A10927@d-131-151-189-65.dynamic.umr.edu> <39CB524E.2EB250E0@uow.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <39CB524E.2EB250E0@uow.edu.au>; from andrewm@uow.edu.au on Fri, Sep 22, 2000 at 11:36:30PM +1100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 5985
Lines: 168

On Fri, Sep 22, 2000 at 11:36:30PM +1100, Andrew Morton wrote:
> [ added netdev ]
> 
> David Fries wrote:
> > 
> > I don't know if it is a motherboard/network card combination, but I
> > see networking going down the tube with nfs traffic the first to show
> > things slowing down.  Sometimes networking completely stops and
> > without any error message.
> > 
> > In previous kernels I just did ifconfig eth0 down, rmmod 3c59x, insmod
> > 3c59x, ifconfig ... and it was back to normal.
> 
> This is unfamiliar and it does sound like a driver problem.  Does it do
> this under kernel 2.2?

yes

I'm going to say there are two problems, 'net drop out' and
'unregister_netdevice'.

> Could you please do some further investigation?  Try increasing the
> driver debug level, look at the `ifconfig' output and /proc/interrupts
> when it's happening, etc?  Thanks.

'net drop out' problem,
There are two stages, reduced network and no network.  For example
when I do a `ping -s 15000 aerospace` ping from spacedout (troubled
computer) to aerospace (another one), I'll get response times of
either 4ms or 3000ms.

When networking stops I don't get any packets received or interrupts,
but I and showing RX overruns incrementing.  When I ping from
spacedout, spacedout shows an arp request going out, aerospace sees
the arp request, but spacedout never sees the reply.

> > Now I booted the 2.4.0-test9 pre4 kernel ( the test8 did it also, but
> > I think I could unload under test7).  This is with a 3c509B network
> > card.
> > 
> > With 2.4.0-test9 it gives me,
> > 
> > unregister_netdevice: waiting for eth0 to become free.  Usage count =
> > 2
> > 
> > and that keeps scrolling on the screen.
> 
> And does it continue to do this for more than thirty seconds?

yes.

> If so, then someone may be leaking some skbuffs.
> 
> Is this an NFS server or a client?

both problems
It is a client, but it doesn't matter if I have NFS mounted or not.
It will happen without NFS so that shouldn't matter.

> What NFS mount options are you using (specifically, rsize and wsize)?
> 
> I've just tried an ifdown/rmmod in the middle of heavy NFS client
> traffic and everything seems to hang together, although the application
> which is using NFS gets errors when the interface is brought back up.  
> (Is NFS client supposed to be able to recover from a local interface
> outage??)

I not sure, I think it should work, but it would matter on your mount
options.

> Are you able to provide a set of steps with which others can reproduce
> this?

'net drop out'
I'll just say no.  AeroSpace is running SMP, spacedout is not SMP.
AeroSpace is a dual Pentium MMX, Spacedout is a K6-2.  They have
basically identical network cards in them 3c905b, I have swaped the
network cards in the past and the problems follow the computer not the
card.

I would suggest try getting a FIC VA 503+ motherboard, K6-2 processor,
3c905B network card, go in X, have something rapidly updating the
video card (rxvt doing `locate \*` worked fine), and send a ton of
network data to the system at 100BaseT.

If you REALLY pulled my leg you might get me to put one of my Pentium
processors in the system, but I would rather not do that.

The new problem about 'unregister_netdevice: waiting ...' I can
reproduce it by,
insmod 3c59x
ifconfig eth0 ...
(on another console) ping -s 15000 -f aerospace
ifconfig eth0 down; rmmod 3c59x

That usually gives about two lines of 'unregister_netdevice...' before
is able to be removed.

Odd thing about the 'unregister_netdevice' problem is I was still able
to unload the module until I inserted my ne2000 card and ifconfiged it
up.

I did,
insmod 3c59x
modprobe ne io=0x300 irq=111
ifconfig eth0 ...
ifconfig eth1 ...
ifconfig eth0 down
rmmod 3c59x
and it keep giving, 'unregister_netdevice' message over and over until
I rebooted.

This is having init run sulogin as about the first thing it does, so
there isn't anything else up on the system yet.

> Are you running SMP?  I assume not, because if you were, your kernel
> would have locked up good and tight.
> 
> Alexey, Dave: that wait-for-ever crap which went into
> unregister_netdevice() happens under the lock_kernel() in
> sys_delete_module()!  This means that the kernel lock will be held until
> all the frags expire.  Ugly.  Is sys_delete_module() the only user of
> unregister_netdevice who can get bitten by this?
> 
> > If I run ifconfig it hangs, doing strace ifconfig shows it hangs on
> > the ioctl ( SIOCGIFCONF) call.
> 
> Possibly the rtnetlink semaphore. Not sure.
> 
> > /proc/net/dev does not list an eth0 device
> > /proc/modules lists 3c59x 21992  0 (deleted)
> 
> OK, you're not using SMP :)
> 
> > I need the latest kernel or usb crashes, but if networking goes down
> > I'm SOL, time to reboot which is just as annoying.
> > 
> > I'm open to suggestions.
> 
> David, it would be useful if you could play with this or an hour or so
> and characterise it a bit more.  It sounds nicely reproducible, which is
> good.  But how do I reproduce it here?

Where is here?  I'm in USA, Missouri.

I'm guessing for the 'unregister_netdevice' put an ne2000 card in and
that might be enough.

For the 'net drop out' problem you might need the same model
motherboard I have.

The the driver for this network card 3c905b, uses a circular buffer
list for it's receive buffer right?  Could you modify the receive
routine to build a histogram that records which buffer each packet is
being received from?  Each second spit out a list that gives each
buffer number and the total number of packets received from that buffer.

I'm wondering if in my case buffers and getting stuck and it has less
buffers to work with causing lower network performance and sometimes
everything is full and it stops receiving.

Then again I haven't looked at the card in detail or driver.

-- 
		+---------------------------------+
		|      David Fries                |
		|      dfries@umr.edu             |
		+---------------------------------+

From owner-netdev@oss.sgi.com Fri Sep 22 20:43:17 2000
Received:  by oss.sgi.com id <S42232AbQIWDm6>;
	Fri, 22 Sep 2000 20:42:58 -0700
Received: from mrelay.cc.umr.edu ([131.151.1.89]:46344 "EHLO smtp.umr.edu")
	by oss.sgi.com with ESMTP id <S42226AbQIWDm2>;
	Fri, 22 Sep 2000 20:42:28 -0700
Received: from d-131-151-189-65.dynamic.umr.edu (d-131-151-189-65.dynamic.umr.edu [131.151.189.65]) via ESMTP by mrelay.cc.umr.edu (8.9.3/R.4.20) id WAA24088; Fri, 22 Sep 2000 22:42:24 -0500
Received: (from david@localhost)
	by d-131-151-189-65.dynamic.umr.edu (8.11.0/8.11.0/Debian 8.11.0-1) id e8N3fKl30701;
	Fri, 22 Sep 2000 22:41:20 -0500
Date:   Fri, 22 Sep 2000 22:41:20 -0500
From:   David Fries <dfries@umr.edu>
To:     Andrew Morton <andrewm@uow.edu.au>
Cc:     vortex@scyld.com, netdev@oss.sgi.com
Subject: Re: [vortex] can't unload module
Message-ID: <20000922224120.C24813@d-131-151-189-65.dynamic.umr.edu>
References: <20000921002752.A10927@d-131-151-189-65.dynamic.umr.edu> <39CB524E.2EB250E0@uow.edu.au> <20000922153900.A24813@d-131-151-189-65.dynamic.umr.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20000922153900.A24813@d-131-151-189-65.dynamic.umr.edu>; from dfries@umr.edu on Fri, Sep 22, 2000 at 03:39:00PM -0500
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1787
Lines: 49

On Fri, Sep 22, 2000 at 03:39:00PM -0500, David Fries wrote:
> The new problem about 'unregister_netdevice: waiting ...' I can
> reproduce it by,
> insmod 3c59x
> ifconfig eth0 ...
> (on another console) ping -s 15000 -f aerospace
> ifconfig eth0 down; rmmod 3c59x
> 
> That usually gives about two lines of 'unregister_netdevice...' before
> is able to be removed.
> 
> Odd thing about the 'unregister_netdevice' problem is I was still able
> to unload the module until I inserted my ne2000 card and ifconfiged it
> up.

It looks like I have to unload the network modules in the opposite
order I loaded them.  That doesn't sound right.

> I did,
> insmod 3c59x
> modprobe ne io=0x300 irq=111
> ifconfig eth0 ...
> ifconfig eth1 ...
> ifconfig eth0 down
> rmmod 3c59x
> and it keep giving, 'unregister_netdevice' message over and over until
> I rebooted.

> The the driver for this network card 3c905b, uses a circular buffer
> list for it's receive buffer right?  Could you modify the receive
> routine to build a histogram that records which buffer each packet is
> being received from?  Each second spit out a list that gives each
> buffer number and the total number of packets received from that buffer.
> 
> I'm wondering if in my case buffers and getting stuck and it has less
> buffers to work with causing lower network performance and sometimes
> everything is full and it stops receiving.
> 
> Then again I haven't looked at the card in detail or driver.

That doesn't look like the case.  I implimented the histogram and in
boomerang_rx I counted which entry it dealt with and they were all
with in one of each other.

-- 
		+---------------------------------+
		|      David Fries                |
		|      dfries@umr.edu             |
		+---------------------------------+

From owner-netdev@oss.sgi.com Fri Sep 22 23:18:12 2000
Received:  by oss.sgi.com id <S42258AbQIWGSC>;
	Fri, 22 Sep 2000 23:18:02 -0700
Received: from mrelay.cc.umr.edu ([131.151.1.89]:1546 "EHLO smtp.umr.edu")
	by oss.sgi.com with ESMTP id <S42226AbQIWGRm>;
	Fri, 22 Sep 2000 23:17:42 -0700
Received: from d-131-151-189-65.dynamic.umr.edu (d-131-151-189-65.dynamic.umr.edu [131.151.189.65]) via ESMTP by mrelay.cc.umr.edu (8.9.3/R.4.20) id BAA18871; Sat, 23 Sep 2000 01:17:41 -0500
Received: (from david@localhost)
	by d-131-151-189-65.dynamic.umr.edu (8.11.0/8.11.0/Debian 8.11.0-1) id e8N6GRT31189;
	Sat, 23 Sep 2000 01:16:27 -0500
Date:   Sat, 23 Sep 2000 01:16:27 -0500
From:   David Fries <dfries@umr.edu>
To:     Andrew Morton <andrewm@uow.edu.au>
Cc:     vortex@scyld.com, netdev@oss.sgi.com
Subject: Re: [vortex] overrun problem
Message-ID: <20000923011627.D24813@d-131-151-189-65.dynamic.umr.edu>
References: <20000921002752.A10927@d-131-151-189-65.dynamic.umr.edu> <39CB524E.2EB250E0@uow.edu.au> <20000922153900.A24813@d-131-151-189-65.dynamic.umr.edu> <20000922224120.C24813@d-131-151-189-65.dynamic.umr.edu>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="LQksG6bCIzRHxTLp"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20000922224120.C24813@d-131-151-189-65.dynamic.umr.edu>; from dfries@umr.edu on Fri, Sep 22, 2000 at 10:41:20PM -0500
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 6131
Lines: 115


--LQksG6bCIzRHxTLp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

I've been hacking away at the driver to get some more information.
I've included my changes, they are against the driver in the
2.4.0-test9-pre4 kernel.

I've setup a timer to run every 20 seconds and if there are less than
20 packets sent go though the rx_ring and print out any status that
was not zero.  I then reset the card using vortex_down, vortex_up.
Like ifconfiging the interface down and back up, it seems to help, but
the network card isn't fully functional until I rmmod and insmod it.

Sep 22 23:45:33 spacedout kernel: Ring 1, status 0x803c
Sep 22 23:45:33 spacedout kernel: Ring 5, status 0x600085ea
Sep 22 23:45:33 spacedout kernel: Ring 23, status 0x803c
Sep 22 23:45:33 spacedout kernel: Ring 27, status 0x803c
Sep 22 23:45:33 spacedout kernel: Ring 29, status 0x803c

Sep 22 23:53:35 spacedout kernel: Ring 3, status 0x600085ea
Sep 22 23:53:35 spacedout kernel: Ring 5, status 0x600085ea
Sep 22 23:53:35 spacedout kernel: Ring 7, status 0x450008
Sep 22 23:53:35 spacedout kernel: Ring 8, status 0x978341bd
Sep 22 23:53:35 spacedout kernel: Ring 9, status 0x10808c88
Sep 22 23:53:35 spacedout kernel: Ring 10, status 0xd00d0ef
Sep 22 23:53:35 spacedout kernel: Packets diff 0

Sep 22 23:57:49 spacedout kernel: Ring 11, status 0x600085ea
Sep 22 23:57:49 spacedout kernel: Ring 13, status 0x450008
Sep 22 23:57:49 spacedout kernel: Ring 14, status 0x978341bd
Sep 22 23:57:49 spacedout kernel: Ring 15, status 0x108086ee
Sep 22 23:57:49 spacedout kernel: Ring 16, status 0xd004151
Sep 22 23:57:49 spacedout kernel: Packets diff 0

Sep 23 00:13:52 spacedout kernel: Ring 3, status 0x600085ea
Sep 23 00:13:52 spacedout kernel: Ring 5, status 0x450008
Sep 23 00:13:52 spacedout kernel: Ring 6, status 0x978341bd
Sep 23 00:13:52 spacedout kernel: Ring 7, status 0x1080c165
Sep 23 00:13:52 spacedout kernel: Ring 8, status 0xf00c0cc

What does rmmod and insmod do to the network card that vortex_down,
vortex_up doesn't?  Something is different.

I'll assume the problem is the fifo isn't being empied and overruns
for whatever reason (the video card is hoggin the bus?), what is
supposed to happen?  The NIC puts down the status, moves it's pointer
to the next ring entry, gets the next packet, signals that it uploaded
a packet, the driver wakes up, the while loop in boomerang_rx says
RxDComplete not set, it goes to sleep.  This keeps happening until the
NIC goes around the ring.

Maybe that senerio isn't quite right, but I'm not sure what is
supposed to happen next.

My feeling is there is some problem here.  I'll try working on it
tomorrow some more.

-- 
		+---------------------------------+
		|      David Fries                |
		|      dfries@umr.edu             |
		+---------------------------------+

--LQksG6bCIzRHxTLp
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="3c59x.diff.gz"
Content-Transfer-Encoding: base64

H4sICOxCzDkAAzNjNTl4LmRpZmYAvVhZb9tIEn6WsD+ioB0nkqmDlKzYkiMjTuydGIkPyMlm
kaxBtMim1WuKzfDQgYznt29Vd1OiHHkGiwFWD7y66676qloXkc+XQ+h5/cGy7VVHf/1XHb+7
hUCEfAidPE06aeJ1QhHly443T91EyqwT8axjJDbn1YRnieBzEd1DgrdUyAictvPM917VF0EA
rRxaCe5S11611WoVNlS6tm137EGn2wPbGTr9YW9QIX6WZe3c0x8eOMOuUyE+b95Ayxn0m4dg
6dubN1X4u4i8MPc5vNZ2+Dxkq/b0pApVSDOWCQ+8KUtgzhNS8tsduK5PiovMZxmDUbVVM4KH
Hz+gKu0BQBdueQykB8CZjFjow1vuPfAEWOSDzKbIrA3TLIuHnc5isWin3ir0256ckfsWMnno
zGWS8WV7ms1CqEHtl7Hx0pDcB7/8O6odV63/u+SekYzOubw++/zx3D39/On99bhe2xb2eqLu
b9bcT2qN4zXN2fntu/HFzaeL66t6rfdOznToMG0GNl37h31IOeZHCv9UynTeSjnjCYvuO+9W
XigjDn4iMCTElcL6qu80X4FFNx3WSmcfPk05JteMCSwDtD+ht5Bl3IdMYlBFrALMmzCTaRau
YMZ9wVBwyL0M7W3DfgcZpVmSexlkAhVwQ5Gax+NKhWRcbtPotWcpk6WLhrgFA6QfLyF9mAAL
Q+kxxYEqY6WJiI21g80UL9KNExFlxAfZqGeQeQZMr94nbAYygMWUZTDJgwDjDlM25zDhPII8
RS8oJRVdTJJTMklb9Rm930p5lrFJyGEmUq9tHF7sNSbmUSruI+RFbJT/XIm7EuHz4UETFLMb
lqK0loiMg7NVzA15xecBy8PMVStIYeSPOfMhSDAxMGHh/PxmfH3Z+RL13HcyCsS9oqawH3YH
FPbDnm3CbiqWtNFp7ArpZWHd+BBTXBWvx2Ef700w30WQ8O+wn3xvKlJv5lO2GmZzKfyCW7ZU
wUNHP8PyKR3zYuGiJ90v1x+fJ7HKJFvRra89jFl/j0l8TxL+VgWV3yItwoIBTeGlCc5LSvAY
3a7ct/F6E4I8DFt+Hod8CUHI7pvAM08HAxleK3LwZI5OCMVMYGpEWBiIv3mk3nWkeRIwD+VR
SaV5HJNv/HVQHPtIRcWxB+tq1GG9JmbMR30zkXKl3D/OSvoVWYW/edw6KXZSk3gxgt/tpd09
tY/1hpkvpLtIUKW6iiQRxNNV+s2+a8KBfi8xICcTmXLrQ732BSmJ74YN4lpD836kK10etT3O
oKvsoabhdLVBxL5czW3dDGA7Xg1U7XjX7iCPNF6MtjEBgdWqUG/R7/UXRLmVEMqQn77+kfhd
20vyt8Fk526+jEWC8R7B+POVe/qp3rX3339VmjDf/0NVCWECqJvy8fkkv4cTcBrkYhOLD+fj
K2wJbz//CrW9dAgXaL5gYSkvYC9tY3iaKjoAgGa1TiI2I+hWmJNNwm/qowhcysa7Nq2a3tC1
D3sUv6591G0e6fAhyOZJBJRMj+Rzqnql+7fxv9zxxdWv7u3F1/M7tPiH/ajM2CBLFSZFN3KT
5XNFXYUfWrpzoLKn6/R7m2pQyoYszZADCvkPTj3Y7XT6kR9JWtrG1IgZ9tEstaxjnZSYxFpP
HmGbuDPf1QuF37KI2ssT5NuAPShbc6wyGjS+4gwXqgLEBpRQIZgesa7irnPoaL2Pes2+s9tt
JdiqWn+GW1Xrh0puhNuRfWweM5lhqEegPpTQW/nmyeIuP5PRO1YaKLBEZNIPdZtjw4f9eVyi
e7rYUMGh10LJK1IsT9eaxCJysV8/uCL5rvOe3lQ9mJzWmaw8MoRac5OxoHYFMqnDMQh4vR0h
EJaFfqqQozasAPb84Z6PbETTZKm404CmPGSNio/07XGjRU1jGhoR1MsetXBAxCrUL2t5mBfe
FMc2VEmnhLFaDSGkMtSFcsHzemtGSpyBPGKEirUNL7XJ7FprOSZhe36zEGgv9w6WVO9k704+
BZqbwIwc/a7KQ11QA7NWUquQd6NrCtRZY89XkrQvWmUvaSGKXaUUjxoiIU5GqE/hXfLcBY5+
1I49liIqTUK5UNXlsQRngAVbGS8WOCgXUd20/kplwRDv0b8uzsnYmQmXdU/7RHqMSRz8hl4J
Ar3fMMljzULJP/1wcznEIsbZCDbrDcAhIJ9xGgRwDiSNElPvqCsNA224wMEN9Yskzol6LtM5
tFWB6k44aFVm8nnEbxYN4v1X2MckazQ0jaoYHCF21swjzR5VQIILnFf5S5xRp4IGWS38+voS
Z2LCK1K7DFkLDrFEGJMRljwN4Z6MfMWIkjVFjMb2MJPJCn1yTSefhZk6cGxB8yMJFBgclTCi
GUvW/okTidNN2tY42LU1Dnb7Rwa/EQjxlKid4KaryNP2lBu5miR2bSpWrZ2rT9snmIMMga7E
ZFUAmSJGpnB6e3qDdn3hkMc+4da6bWAYMf3MKIWT6qJ+S5/PRErTPBaVxKadIAicf8SB+vKs
aJO97oEytLdpk8SiPJpqUa4SU1fArpmtB+ldXXCN65ogUscg09cKSF0vBSKQLh4gZKK64V/F
b3O+CX13gadALMoRSlnUd7gAjBN6h03ngLwwwIej9VnyEk8pAosTh2NMxLQ4AiHSRJMNu26j
mPZ0A99sRgyxSHZpc+/JZjxbaCWN/T9THCBFa3s+KPnr5/399bD47P7SO+ygfqKfidoOY179
yeb61u5B44W97NkNeP0aDsgmfRIuKMivTzx72DjGwU8Fgs7RdD6kQ3zImTklP+VQmp1G/yMz
XXNLbNo4ESUsTGGHQkfKYNx4JqOXCJ3qrxVYiGyKDO+xSPFt0AQWAV9mPFJ/cOF5vFhL4dWL
wzZyQEUU7IEv6RCnMAiXYM7CnOsDHMvkDMvH1LlCdH1QYxM8bGseiGciQhrhGwinHlwO7tOx
ovbAk4iHW3uoB9MfDPgU4mNENVu8ouYex6OmbpclqibsGlib5SJv6LkEtlNxssrQQOtJRTr2
z5n0zM5uEYIrvhji4VI5S/9hRA6dUXAxekVkafUt829vz/QJ1/xP81+MFKmpJRUAAA==

--LQksG6bCIzRHxTLp--

From owner-netdev@oss.sgi.com Sat Sep 23 05:30:45 2000
Received:  by oss.sgi.com id <S42264AbQIWMaZ>;
	Sat, 23 Sep 2000 05:30:25 -0700
Received: from horus.its.uow.edu.au ([130.130.68.25]:7341 "EHLO
        horus.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42261AbQIWMaB>;
	Sat, 23 Sep 2000 05:30:01 -0700
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 XAA20961;
	Sat, 23 Sep 2000 23:29:40 +1100 (EST)
Message-ID: <39CCA283.74E63C9A@uow.edu.au>
Date:   Sat, 23 Sep 2000 23:30:59 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8-pre1 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     David Fries <dfries@umr.edu>
CC:     vortex@scyld.com, netdev@oss.sgi.com
Subject: Re: [vortex] can't unload module
References: <20000921002752.A10927@d-131-151-189-65.dynamic.umr.edu> <39CB524E.2EB250E0@uow.edu.au>,
		<39CB524E.2EB250E0@uow.edu.au>; from andrewm@uow.edu.au on Fri, Sep 22, 2000 at 11:36:30PM +1100 <20000922153900.A24813@d-131-151-189-65.dynamic.umr.edu>
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
Content-Length: 4316
Lines: 118

David Fries wrote:
> 
> 'net drop out' problem,
> There are two stages, reduced network and no network.  For example
> when I do a `ping -s 15000 aerospace` ping from spacedout (troubled
> computer) to aerospace (another one), I'll get response times of
> either 4ms or 3000ms.
> 
> When networking stops I don't get any packets received or interrupts,
> but I and showing RX overruns incrementing.  When I ping from
> spacedout, spacedout shows an arp request going out, aerospace sees
> the arp request, but spacedout never sees the reply.

This is consistent with an interrupt controller failure.  However if
this was the case you should be seeing "NETDEV WATCHDOG: eth0: transmit
timed out" messages and "interrupt posted but not delivered" messages. 
Are you sure you're not?

Another test: when spacedout is in this state, go to its console and
ping another machine.  Watch /proc/interrupts to see if you're getting
Tx interrupts.

If you are getting tx interrupts then perhaps the NIC is getting its
registers unprogrammed, or perhaps the multicast filter has gone silly. 
Try `ifconfig eth0 promisc'.

Or try a new PCI slot.

Or a new power supply.

Or a new computer.

BTW, I'm currently typing on a K6-2 machine (wildly overclocked - this
is my main workstation/router/firewall/server :)).  It's running
2.4.0-test8-pre1 with a 3c905B.  Solid as a rock.  Different motherboard
manufacturer: Gigabyte.

> I not sure, I think it should work, but it would matter on your mount
> options.

OK, I was asking because this problem is related to IP fragmentation,
and I assume (perhaps wrongly) that if rsize and wsize are larger than
your MTU, there will be a lot of fragmented packets.

> > Are you able to provide a set of steps with which others can reproduce
> > this?
> 
> 'net drop out'
> I'll just say no.  AeroSpace is running SMP, spacedout is not SMP.
> AeroSpace is a dual Pentium MMX, Spacedout is a K6-2.  They have
> basically identical network cards in them 3c905b, I have swaped the
> network cards in the past and the problems follow the computer not the
> card.
> 
> I would suggest try getting a FIC VA 503+ motherboard, K6-2 processor,
> 3c905B network card, go in X, have something rapidly updating the
> video card (rxvt doing `locate \*` worked fine), and send a ton of
> network data to the system at 100BaseT.

I just did that here:

	ping -q -f -s 64 -l 100000 bix

This caused `bix' to take a short trip to an alternate universe, but it
recovered fine when I killed the ping.

> If you REALLY pulled my leg you might get me to put one of my Pentium
> processors in the system, but I would rather not do that.

Sorry, I think you need to start swapping hardware in spacedout.  It's
sick.

> The new problem about 'unregister_netdevice: waiting ...' I can
> reproduce it by,
> insmod 3c59x
> ifconfig eth0 ...
> (on another console) ping -s 15000 -f aerospace
> ifconfig eth0 down; rmmod 3c59x
> 
> That usually gives about two lines of 'unregister_netdevice...' before
> is able to be removed.

That's normal.  There are orphaned IP fragments floating about in your
kernel.  They have a thirty second lifetime.  When they have all expired
the module unload is allowed to proceed.

> Odd thing about the 'unregister_netdevice' problem is I was still able
> to unload the module until I inserted my ne2000 card and ifconfiged it
> up.
> 
> I did,
> insmod 3c59x
> modprobe ne io=0x300 irq=111
> ifconfig eth0 ...
> ifconfig eth1 ...
> ifconfig eth0 down
> rmmod 3c59x
> and it keep giving, 'unregister_netdevice' message over and over until
> I rebooted.

I tried many combinations of this with a eepro100 and a 3c905C. 
Everything worked fine.  Sigh.

[ In reply to a later email ]

> What does rmmod and insmod do to the network card that vortex_down,
> vortex_up doesn't?  Something is different.

All the stuff in vortex_probe1() is run at insmod-time only.  It's
mainly driver data structure initialisation, but there's some hardware
initialisation as well.


David, If this problem is purely exhibited on `spacedout' then it's
quite possible that there are no software problems, although that
unregister_netdevice problem sure looks like software to me...   My
recommendation is to start swapping out hardware.  You get some
amazingly wierd stuff happening if the hardware is dodgy.

From owner-netdev@oss.sgi.com Sat Sep 23 11:52:15 2000
Received:  by oss.sgi.com id <S42271AbQIWSwG>;
	Sat, 23 Sep 2000 11:52:06 -0700
Received: from u-122.karlsruhe.ipdial.viaginterkom.de ([62.180.21.122]:9732
        "EHLO u-122.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com
	with ESMTP id <S42261AbQIWSvt>; Sat, 23 Sep 2000 11:51:49 -0700
Received: (ralf@lappi) by lappi.waldorf-gmbh.de id <S869537AbQIVS2Y>;
        Fri, 22 Sep 2000 20:28:24 +0200
Date:   Fri, 22 Sep 2000 20:28:24 +0200
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Rabeeh Khoury <rabeeh@galileo.co.il>
Cc:     netdev <netdev@oss.sgi.com>
Subject: Re: forwarding packets
Message-ID: <20000922202824.A886@bacchus.dhis.org>
References: <39C7AD0D.84CEDBD9@galileo.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <39C7AD0D.84CEDBD9@galileo.co.il>; from rabeeh@galileo.co.il on Tue, Sep 19, 2000 at 02:14:37PM -0400
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
Content-Length: 2142
Lines: 51

On Tue, Sep 19, 2000 at 02:14:37PM -0400, Rabeeh Khoury wrote:

> I am working on a Galileo Technology evaluation board. I'm writing
> ethernet driver for our embedded systems and I have to ethernet ports.
> 
> I need to ask if there is a way for implementing the following scenario
> for the ethernet drivers to be activated as two ethernet ports router :
> 
> 1.. The ethernet driver receives a packet
> 2.. The ethernet driver checks if the packet should be forwarded to
> another interface. The checking is done by query to the kernel routing
> table.
> 3.. If the packet should be forwarded, the ethernet driver queues the
> packet to the destination interface with slight changes (source and
> destination MAC addresses).
> 
> If this scenario possible, please send me the functions that I should
> use. (dev_queue_xmit for queing a packet to another interface ??!!)
> 
> The main motive in this scenario is that I don't want that the packet to
> be handed to the kernel IP stack, then to decide if it should be routed
> or not ; I want from the ethernet driver to know if the packet should be
> routed or not, and if to be routed to which interface.
> 
> Another question :
> How can I know from the sk_buff when handed to the ethernet driver, if
> it is a routed packet or it's origin is from the local CPU ?
> 
> p.s. I'm using kernel 2.2.14 (MIPS based CPU)

Sounds like what you want is CONFIG_NET_FASTROUTE; here's what
Documentation/Configure says about it:

CONFIG_NET_FASTROUTE
  Saying Y here enables direct NIC-to-NIC (NIC = Network Interface
  Card) data transfers on the local network, which is fast.

  IMPORTANT NOTE: This option is NOT COMPATIBLE with "Network packet
  filtering" (CONFIG_NETFILTER). Say N here if you say Y there.

  However, it will work with all options in the "IP: advanced router"
  section (except for "IP: use TOS value as routing key" and
  "IP: use FWMARK value as routing key").

  At the moment, few devices support fast switching (tulip is one of
  them, a modified 8390 driver can be found at
  ftp://ftp.inr.ac.ru/ip-routing/fastroute/fastroute-8390.tar.gz ).

  If unsure, say N.

  Ralf

From owner-netdev@oss.sgi.com Sat Sep 23 22:48:00 2000
Received:  by oss.sgi.com id <S42278AbQIXFrv>;
	Sat, 23 Sep 2000 22:47:51 -0700
Received: from mrelay.cc.umr.edu ([131.151.1.89]:30221 "EHLO smtp.umr.edu")
	by oss.sgi.com with ESMTP id <S42261AbQIXFra>;
	Sat, 23 Sep 2000 22:47:30 -0700
Received: from d-131-151-189-65.dynamic.umr.edu (d-131-151-189-65.dynamic.umr.edu [131.151.189.65]) via ESMTP by mrelay.cc.umr.edu (8.9.3/R.4.20) id AAA00953; Sun, 24 Sep 2000 00:47:28 -0500
Received: (from david@localhost)
	by d-131-151-189-65.dynamic.umr.edu (8.11.0/8.11.0/Debian 8.11.0-1) id e8O5kHa18551;
	Sun, 24 Sep 2000 00:46:17 -0500
Date:   Sun, 24 Sep 2000 00:46:17 -0500
From:   David Fries <dfries@umr.edu>
To:     Andrew Morton <andrewm@uow.edu.au>
Cc:     vortex@scyld.com, netdev@oss.sgi.com
Subject: Re: [vortex] can't unload module
Message-ID: <20000924004617.A18466@d-131-151-189-65.dynamic.umr.edu>
References: <20000921002752.A10927@d-131-151-189-65.dynamic.umr.edu> <39CB524E.2EB250E0@uow.edu.au>, <39CB524E.2EB250E0@uow.edu.au>; <20000922153900.A24813@d-131-151-189-65.dynamic.umr.edu> <39CCA283.74E63C9A@uow.edu.au>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <39CCA283.74E63C9A@uow.edu.au>; from andrewm@uow.edu.au on Sat, Sep 23, 2000 at 11:30:59PM +1100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 8876
Lines: 217


--BXVAT5kNtrzKuDFl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

I've included my latest patch.  I've narrowed it do to in
boomerange_rx if there is a status field non-null in the entry before
vp->cur_rx, I start at vp->cur_rx, skip the entries that the status
says they are completed uploading and set the status fields of all
the rest of the entries to zero.

I don't know enough to tell if there is data in the entry that has a
status field, so yes I'm just throwing it away.

For me this works, I haven't had networking go down with this patch.
I am getting 'NETDEV WATCHDOG: eth0: transmit timed out' which I
hadn't gotten before, but then it might be possible that networking
went down before it got to that point.

Here are some of my kernel log messages with this patch.

Sep 23 22:52:14 spacedout kernel: bucket 0, status 0x0
Sep 23 22:52:14 spacedout kernel: bucket 1, status 0x600085ea
Sep 23 22:52:14 spacedout kernel: vp->cur_rx 2
Sep 23 22:52:14 spacedout kernel: bucket 0, status 0x0
Sep 23 22:52:14 spacedout kernel: bucket 1, status 0x600085ea
Sep 23 22:52:14 spacedout kernel: vp->cur_rx 2
Sep 23 22:52:14 spacedout kernel: bucket 22, status 0x0
Sep 23 22:52:14 spacedout kernel: bucket 23, status 0x600085ea
Sep 23 22:52:14 spacedout kernel: vp->cur_rx 24
Sep 23 22:52:14 spacedout kernel: bucket 10, status 0x0
Sep 23 22:52:14 spacedout kernel: bucket 11, status 0x600085ea
Sep 23 22:52:14 spacedout kernel: vp->cur_rx 12
Sep 23 22:52:15 spacedout kernel: bucket 16, status 0x0
Sep 23 22:52:15 spacedout kernel: bucket 17, status 0x600085ea
Sep 23 22:52:15 spacedout kernel: vp->cur_rx 18
Sep 23 22:52:17 spacedout kernel: bucket 2, status 0x0
Sep 23 22:52:17 spacedout kernel: bucket 3, status 0x600085ea
Sep 23 22:52:17 spacedout kernel: vp->cur_rx 4
Sep 23 22:52:17 spacedout kernel: bucket 0, status 0x0
Sep 23 22:52:17 spacedout kernel: bucket 1, status 0x600085ea
Sep 23 22:52:17 spacedout kernel: vp->cur_rx 2
Sep 23 22:52:19 spacedout kernel: bucket 2, status 0x0
Sep 23 22:52:19 spacedout kernel: bucket 3, status 0x600085ea
Sep 23 22:52:19 spacedout kernel: vp->cur_rx 4
Sep 23 22:52:19 spacedout kernel: bucket 12, status 0x0
Sep 23 22:52:19 spacedout kernel: bucket 13, status 0x600085ea
Sep 23 22:52:19 spacedout kernel: vp->cur_rx 14
Sep 23 22:52:19 spacedout kernel: bucket 0, status 0x0
Sep 23 22:52:19 spacedout kernel: bucket 1, status 0x600085ea
Sep 23 22:52:19 spacedout kernel: vp->cur_rx 2
Sep 23 22:52:20 spacedout kernel: bucket 10, status 0x0
Sep 23 22:52:20 spacedout kernel: bucket 11, status 0x600085ea
Sep 23 22:52:20 spacedout kernel: vp->cur_rx 12
Sep 23 22:52:20 spacedout kernel: bucket 16, status 0x0
Sep 23 22:52:20 spacedout kernel: bucket 17, status 0x600083d2
Sep 23 22:52:20 spacedout kernel: vp->cur_rx 18

Does that give you any clue where I should look more for the real
cause?  Looks like an off by one error, but I wouldn't know how that
would happen.

Instead of clearing the entries I tried the following, but something
didn't like it, because my machine froze in X as soon as I was
pounding the video card and network card at the same time.

/* it doesn't like this
entry--;
vp->cur_rx--;
*/

I'm wondering if the chipset just can't handle multiple devices trying
to do something at once.

On Sat, Sep 23, 2000 at 11:30:59PM +1100, Andrew Morton wrote:
> David Fries wrote:
> > 
> > 'net drop out' problem,
> > There are two stages, reduced network and no network.  For example
> > when I do a `ping -s 15000 aerospace` ping from spacedout (troubled
> > computer) to aerospace (another one), I'll get response times of
> > either 4ms or 3000ms.
> > 
> > When networking stops I don't get any packets received or interrupts,
> > but I and showing RX overruns incrementing.  When I ping from
> > spacedout, spacedout shows an arp request going out, aerospace sees
> > the arp request, but spacedout never sees the reply.
> 
> This is consistent with an interrupt controller failure.  However if
> this was the case you should be seeing "NETDEV WATCHDOG: eth0: transmit
> timed out" messages and "interrupt posted but not delivered" messages. 
> Are you sure you're not?

I'm not getting those message.  Which interrupt controller are you
thinking of?  I think it was only interrupting when I sent packets.

> Another test: when spacedout is in this state, go to its console and
> ping another machine.  Watch /proc/interrupts to see if you're getting
> Tx interrupts.
> 
> If you are getting tx interrupts then perhaps the NIC is getting its
> registers unprogrammed, or perhaps the multicast filter has gone silly. 
> Try `ifconfig eth0 promisc'.
> 
> Or try a new PCI slot.

Did that.

> Or a new power supply.

I have changed power supplies because the fan was getting noisy, but I
don't remember when.

> Or a new computer.

I'd rather not.

> BTW, I'm currently typing on a K6-2 machine (wildly overclocked - this
> is my main workstation/router/firewall/server :)).  It's running
> 2.4.0-test8-pre1 with a 3c905B.  Solid as a rock.  Different motherboard
> manufacturer: Gigabyte.

I really don't see it being related to the processor, motherboard
chipset probably.

> > I not sure, I think it should work, but it would matter on your mount
> > options.
> 
> OK, I was asking because this problem is related to IP fragmentation,
> and I assume (perhaps wrongly) that if rsize and wsize are larger than
> your MTU, there will be a lot of fragmented packets.
> 
> > > Are you able to provide a set of steps with which others can reproduce
> > > this?
> > 
> > 'net drop out'
> > I'll just say no.  AeroSpace is running SMP, spacedout is not SMP.
> > AeroSpace is a dual Pentium MMX, Spacedout is a K6-2.  They have
> > basically identical network cards in them 3c905b, I have swaped the
> > network cards in the past and the problems follow the computer not the
> > card.
> > 
> > I would suggest try getting a FIC VA 503+ motherboard, K6-2 processor,
> > 3c905B network card, go in X, have something rapidly updating the
> > video card (rxvt doing `locate \*` worked fine), and send a ton of
> > network data to the system at 100BaseT.
> 
> I just did that here:
> 
> 	ping -q -f -s 64 -l 100000 bix
> 
> This caused `bix' to take a short trip to an alternate universe, but it
> recovered fine when I killed the ping.
> 
> > If you REALLY pulled my leg you might get me to put one of my Pentium
> > processors in the system, but I would rather not do that.
> 
> Sorry, I think you need to start swapping hardware in spacedout.  It's
> sick.

I would assume that would mean motherboard or network card that gets
along with the motherboard.

> > I did,
> > insmod 3c59x
> > modprobe ne io=0x300 irq=111
> > ifconfig eth0 ...
> > ifconfig eth1 ...
> > ifconfig eth0 down
> > rmmod 3c59x
> > and it keep giving, 'unregister_netdevice' message over and over until
> > I rebooted.
> 
> I tried many combinations of this with a eepro100 and a 3c905C. 
> Everything worked fine.  Sigh.
> 
> [ In reply to a later email ]
> 
> > What does rmmod and insmod do to the network card that vortex_down,
> > vortex_up doesn't?  Something is different.
> 
> All the stuff in vortex_probe1() is run at insmod-time only.  It's
> mainly driver data structure initialisation, but there's some hardware
> initialisation as well.
> 
> David, If this problem is purely exhibited on `spacedout' then it's
> quite possible that there are no software problems, although that
> unregister_netdevice problem sure looks like software to me...   My
> recommendation is to start swapping out hardware.  You get some
> amazingly wierd stuff happening if the hardware is dodgy.

-- 
		+---------------------------------+
		|      David Fries                |
		|      dfries@umr.edu             |
		+---------------------------------+

--BXVAT5kNtrzKuDFl
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="differences.patch.gz"
Content-Transfer-Encoding: base64

H4sICIqQzTkAA2RpZmZlcmVuY2VzLnBhdGNoAI1UXW/aMBR9Dr/iCoktNAmE8KEOBmIrqKq2
9QGKNK1DERDDLMBGwYFUFf9913YSQtWhPWBin3vPPT6+tuM4UBXbXZWHdFVZGOOIwZjswGuA
67a9VrtWB8913YJlWVBfND/F/p5udxsiY2dCx2KI127ctj1Px/b74Hjubc1ugaX+my3o9wtg
bDhbAeWzIAihCwE5OL35bE98udBBnDIBIVYQMxHtcwtHHq79Dd1SgWmHndMLaChe/DAGC0Y/
/dHD470/fvg1BEehiyhErFOwVD61KQtIbMOK86Bbs0HT+/No+ZxPniL3q3uyYRdimk+YCF+6
LrJIniWYihrFILp6VqhTm1Y0GZQx6BV/RrVKlxjKQ0FiPyDzaAU9qCkcMUNxr81vw9GjPxh+
ndxDMU9bCjJGNy7FUgs5JJ+MxEJ9/mZFO6EzEh32NXHvgd4V8LwpvfklD02gifOJtzj/nJtb
eSMRtKzMEGU+JtPSRYyEsqNOuFMVKiVVoSKlp/L4tI+KV62dGT7AKB7ccdmagqgow1hwJiiL
iKIwVH4XXDU7paxnBp30Tx1JqgzKNZAOQSzXtpZkxzHXR+fkzExXe3jFOFSXrzTNbz7po+I8
WqyJgBJN2zrrEKDOZa/jfKqO9D/T7bfVc6nZrmqZm6fkopj5+6Mlp9XO/QKlQBU5r1x0h248
1eM3crx289ITvanKkUfiaE52E4boZmOnj40Fw+91/+7HIGlp5AV8TAJO9uyjgA1dExB/6F5C
uoDTSQtrfcmCqnIqgHyb8E14c8+bZVx/747POd+ScMZWyGSW26nZpUalkbjNjqbWakml46cv
T5NxGdX+BWHdJzuhBQAA

--BXVAT5kNtrzKuDFl--

From owner-netdev@oss.sgi.com Sun Sep 24 04:20:02 2000
Received:  by oss.sgi.com id <S42281AbQIXLTw>;
	Sun, 24 Sep 2000 04:19:52 -0700
Received: from ikar.t17.ds.pwr.wroc.pl ([156.17.210.253]:21776 "HELO
        ikar.t17.ds.pwr.wroc.pl") by oss.sgi.com with SMTP
	id <S42261AbQIXLTh>; Sun, 24 Sep 2000 04:19:37 -0700
Received: by ikar.t17.ds.pwr.wroc.pl (Postfix+IPv6, from userid 1002)
	id 9A049C805D; Sun, 24 Sep 2000 13:19:34 +0200 (CEST)
Date:   Sun, 24 Sep 2000 13:19:34 +0200
From:   Arkadiusz Miskiewicz <misiek@pld.org.pl>
To:     netdev@oss.sgi.com, Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
Subject: scope id question
Message-ID: <20000924131934.A15731@ikar.t17.ds.pwr.wroc.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.4i
X-URL:  http://www.misiek.eu.org/ipv6/
X-Operating-System: Linux sunsite 4.0.20 #119 Tue Jan 16 12:21:53 MET 2001 i986 pld
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 771
Lines: 22


Hi,

I have scope_id (ipv6) related question. Is it required (or maybe optional)
to pass sockaddr_in6 structure with filled sin6_scope_id with interface
number/site prefix to connect() when I want to connect to link-local or
site-local address ?

If it's required then (almost) all currently available v6 applications will
not work with {link,site}-local adresses: connect(): Invalid argument.
on 2.4 kernels.

Draft scopedaddr-format says that quering getaddrinfo() with
only link-local address (without scope id/interface name) is ok
so I assume that connect()tion to link local address
(with sin6_scope_id = 0) should be ok for kernel, too.

Bye,

-- 
Arkadiusz Mi¶kiewicz         http://www.misiek.eu.org/ipv6/
PLD GNU/Linux [IPv6 enabled]    http://www.pld.org.pl/

From owner-netdev@oss.sgi.com Sun Sep 24 05:37:23 2000
Received:  by oss.sgi.com id <S42299AbQIXMhN>;
	Sun, 24 Sep 2000 05:37:13 -0700
Received: from horus.its.uow.edu.au ([130.130.68.25]:22731 "EHLO
        horus.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42261AbQIXMgy>;
	Sun, 24 Sep 2000 05:36:54 -0700
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 XAA23337;
	Sun, 24 Sep 2000 23:36:33 +1100 (EST)
Message-ID: <39CDF5A0.FF52D796@uow.edu.au>
Date:   Sun, 24 Sep 2000 23:37:52 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8-pre1 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     David Fries <dfries@umr.edu>
CC:     vortex@scyld.com, netdev@oss.sgi.com
Subject: Re: [vortex] can't unload module
References: <20000921002752.A10927@d-131-151-189-65.dynamic.umr.edu> <39CB524E.2EB250E0@uow.edu.au>, <39CB524E.2EB250E0@uow.edu.au>; <20000922153900.A24813@d-131-151-189-65.dynamic.umr.edu> <39CCA283.74E63C9A@uow.edu.au>,
		<39CCA283.74E63C9A@uow.edu.au>; from andrewm@uow.edu.au on Sat, Sep 23, 2000 at 11:30:59PM +1100 <20000924004617.A18466@d-131-151-189-65.dynamic.umr.edu>
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
Content-Length: 973
Lines: 33

David Fries wrote:
> 
> I've included my latest patch.

It's possible that the NIC is getting into the upload-stalled state when
it shouldn't. So the "unneeded"

	outw(UpUnstall, ioaddr + EL3_CMD);

is bringing it back to life.  This could be caused by incorrect data
transferred during a bus mastering read.  You could try putting the
above statement into somewhere like boomerang_start_xmit() to give it a
kick occasionally. <subliminal_message>New
motherboard</subliminal_message>.

You can test the upStalled state of the NIC in bit 13 of `inl(ioaddr +
UpPktStatus)'

> /* it doesn't like this
> entry--;
> vp->cur_rx--;
> */

That will sometimes cause `entry' to take the value -1.  Your kernel
will be destroyed secretly and fatally.

> I would assume that would mean motherboard or network card that gets
> along with the motherboard.

Yup.

David, I suggest we cut the Cc:'s from now on - it looks like were not
making progress on the unregister_netdevice problem.

From owner-netdev@oss.sgi.com Sun Sep 24 05:47:42 2000
Received:  by oss.sgi.com id <S42306AbQIXMrc>;
	Sun, 24 Sep 2000 05:47:32 -0700
Received: from horus.its.uow.edu.au ([130.130.68.25]:63439 "EHLO
        horus.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42261AbQIXMrQ>;
	Sun, 24 Sep 2000 05:47:16 -0700
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 XAA24168;
	Sun, 24 Sep 2000 23:47:08 +1100 (EST)
Message-ID: <39CDF81C.E96274A6@uow.edu.au>
Date:   Sun, 24 Sep 2000 23:48:28 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8-pre1 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
CC:     scott@laird.com, dev_webmaster@sgi.com
Subject: Archives of the Linux netdev mailing list
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
Content-Length: 199
Lines: 6

AFAIK, the only archive of netdev was at
http://www.wcug.wwu.edu/lists/netdev/ but this seems to have been taken
down.

Does anyone know whether this is permanent?  Is netdev archived anywhere
else?

From owner-netdev@oss.sgi.com Sun Sep 24 05:48:22 2000
Received:  by oss.sgi.com id <S42304AbQIXMsC>;
	Sun, 24 Sep 2000 05:48:02 -0700
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:7 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S42261AbQIXMrx>; Sun, 24 Sep 2000 05:47:53 -0700
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 VAA04892;
	Sun, 24 Sep 2000 21:47:26 +0900
To:     misiek@pld.org.pl
Cc:     netdev@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: Re: scope id question
In-Reply-To: <20000924131934.A15731@ikar.t17.ds.pwr.wroc.pl>
References: <20000924131934.A15731@ikar.t17.ds.pwr.wroc.pl>
X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI)
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: <20000924214726Q.yoshfuji@ecei.tohoku.ac.jp>
Date:   Sun, 24 Sep 2000 21:47:26 +0900
From:   Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) 
        <yoshfuji@ecei.tohoku.ac.jp>
X-Dispatcher: imput version 990905(IM130)
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 2304
Lines: 76

In article <20000924131934.A15731@ikar.t17.ds.pwr.wroc.pl> (at Sun, 24 Sep 2000 13:19:34 +0200), Arkadiusz Miskiewicz <misiek@pld.org.pl> says:

> Draft scopedaddr-format says that quering getaddrinfo() with
> only link-local address (without scope id/interface name) is ok
> so I assume that connect()tion to link local address
> (with sin6_scope_id = 0) should be ok for kernel, too.

Does this help you?

Index: af_inet6.c
===================================================================
RCS file: /cvsroot/usagi/kernel/linux24/net/ipv6/af_inet6.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- af_inet6.c	2000/08/25 02:29:26	1.1
+++ af_inet6.c	2000/09/24 12:36:38	1.2
@@ -269,11 +269,13 @@
 			sk->bound_dev_if = addr->sin6_scope_id;
 		}
 
+#ifndef CONFIG_IPV6_LOOSE_SCOPE_ID
 		/* Binding to link-local address requires an interface */
 		if (sk->bound_dev_if == 0) {
 			release_sock(sk);
 			return -EINVAL;
 		}
+#endif
 	}
 
 	sk->rcv_saddr = v4addr;
Index: tcp_ipv6.c
===================================================================
RCS file: /cvsroot/usagi/kernel/linux24/net/ipv6/tcp_ipv6.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- tcp_ipv6.c	2000/08/25 02:29:26	1.1
+++ tcp_ipv6.c	2000/09/24 12:36:38	1.2
@@ -561,9 +561,11 @@
 			sk->bound_dev_if = usin->sin6_scope_id;
 		}
 
+#ifndef CONFIG_IPV6_LOOSE_SCOPE_ID
 		/* Connect to link-local address requires an interface */
 		if (sk->bound_dev_if == 0)
 			return -EINVAL;
+#endif
 	}
 
 	if (tp->ts_recent_stamp && ipv6_addr_cmp(&np->daddr, &usin->sin6_addr)) {
Index: udp.c
===================================================================
RCS file: /cvsroot/usagi/kernel/linux24/net/ipv6/udp.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- udp.c	2000/08/25 02:29:26	1.1
+++ udp.c	2000/09/24 12:36:38	1.2
@@ -291,9 +291,11 @@
 			sk->bound_dev_if = usin->sin6_scope_id;
 		}
 
+#ifndef CONFIG_IPV6_LOOSE_SCOPE_ID
 		/* Connect to link-local address requires an interface */
 		if (sk->bound_dev_if == 0)
 			return -EINVAL;
+#endif
 	}
 
 	ipv6_addr_copy(&np->daddr, daddr);

-- 
Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Sun Sep 24 06:33:24 2000
Received:  by oss.sgi.com id <S42310AbQIXNdN>;
	Sun, 24 Sep 2000 06:33:13 -0700
Received: from u-110.karlsruhe.ipdial.viaginterkom.de ([62.180.21.110]:45573
        "EHLO u-110.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com
	with ESMTP id <S42261AbQIXNcz>; Sun, 24 Sep 2000 06:32:55 -0700
Received: (ralf@lappi) by lappi.waldorf-gmbh.de id <S869550AbQIXNcd>;
        Sun, 24 Sep 2000 15:32:33 +0200
Date:   Sun, 24 Sep 2000 15:32:33 +0200
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Andrew Morton <andrewm@uow.edu.au>
Cc:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>, scott@laird.com,
        dev_webmaster@sgi.com
Subject: Re: Archives of the Linux netdev mailing list
Message-ID: <20000924153233.A16604@bacchus.dhis.org>
References: <39CDF81C.E96274A6@uow.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <39CDF81C.E96274A6@uow.edu.au>; from andrewm@uow.edu.au on Sun, Sep 24, 2000 at 11:48:28PM +1100
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
Content-Length: 517
Lines: 18

On Sun, Sep 24, 2000 at 11:48:28PM +1100, Andrew Morton wrote:

> AFAIK, the only archive of netdev was at
> http://www.wcug.wwu.edu/lists/netdev/ but this seems to have been taken
> down.
> 
> Does anyone know whether this is permanent?  Is netdev archived anywhere
> else?

http://oss.sgi.com/projects/netdev/archive

Btw, I think the project there wants a home page at .../projects/netdev,
if somebody wants to volunteer ...

  Ralf

--
"Embrace, Enhance, Eliminate" - it worked for the pope, it'll work for Bill.

From owner-netdev@oss.sgi.com Sun Sep 24 06:34:33 2000
Received:  by oss.sgi.com id <S42261AbQIXNeX>;
	Sun, 24 Sep 2000 06:34:23 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:22790 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42312AbQIXNeG>;
	Sun, 24 Sep 2000 06:34:06 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id RAA10566; Sun, 24 Sep 2000 17:33:31 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200009241333.RAA10566@ms2.inr.ac.ru>
Subject: Re: scope id question
To:     misiek@pld.ORG.PL (Arkadiusz Miskiewicz)
Date:   Sun, 24 Sep 2000 17:33:31 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <20000924131934.A15731@ikar.t17.ds.pwr.wroc.pl> from "Arkadiusz Miskiewicz" at Sep 24, 0 03:45:01 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 456
Lines: 17

Hello!

> Draft scopedaddr-format says that quering getaddrinfo() with
> only link-local address (without scope id/interface name) is ok

Hence it says a non-sense.


> so I assume that connect()tion to link local address
> (with sin6_scope_id = 0) should be ok for kernel, too.

It is undefined without any doubts. Mapping scoped addresses
without scope id is impossible even theoretically.

No hacks selecting random scope id are to be accepted.

Alexey

From owner-netdev@oss.sgi.com Mon Sep 25 01:38:04 2000
Received:  by oss.sgi.com id <S42312AbQIYIhy>;
	Mon, 25 Sep 2000 01:37:54 -0700
Received: from c208b.mtalo.ton.tut.fi ([193.166.90.201]:32265 "HELO
        c208b.mtalo.ton.tut.fi") by oss.sgi.com with SMTP id <S42229AbQIYIha>;
	Mon, 25 Sep 2000 01:37:30 -0700
Received: (qmail 4582 invoked by uid 500); 25 Sep 2000 08:37:29 -0000
Message-ID: <20000925083729.4581.qmail@c208b.mtalo.ton.tut.fi>
To:     netdev@oss.sgi.com
Subject: 2.4.0-test8: BUG at skbuff.c:93!
Date:   Mon, 25 Sep 2000 11:37:29 +0300
From:   Ilkka Oksanen <ilkka@c208b.mtalo.ton.tut.fi>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 6177
Lines: 165


 I have machine that is router and bridge.
 With 2.4.0-test8 kernel it will crash
 10-20 minutes after boot. Is this bug
 in kernel? 
	
          -ilkka

Error message:

skput:over: c01805f7:592 put:592 dev:eth1kernel BUG at skbuff.c:93!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c019f62d>]
EFLAGS: 00010296
eax: 0000001b ebx: c007d260 ecx: c0225668 edx: 00000000
esi: c1802838 edi: 00000250 ebp: c0f96012 esp: c0239ec4
Process swapper (pid: 0, stackpage=c0239000)
Stack: c020d105 c020d220 0000005d c01805ff c007d260 00000250 c01805f7 00000001
       04000001 c0081140 0000000a 00000250 00007dac c1802838 c1802837 0000024e
       00000252 c0107dac c0530000 c0180b1b c0081000 c0081140 c1802800 c0eb7c00
Call Trace: [<c020d105>] [<c020d220>] [<c01805ff>] [<c01805f7>] [<c1802838>] [<c1802837>] [<c0107dac>] 
       [<c0180b1b>] [<c1802800>] [<c019f850>] [<c180283e>] [<c019fa1b>] [<c1802800>] [<c010a976>] [<c010ab69>]
       [<c01073a0>] [<c0109210>] [<c01073a0>] [<c01073cd>] [<c0107426>] [<c0105000>] [><c01001d0>]
Code: 0f 0b 83 c4 0c c3 90 8b 54 24 04 8b 42 18 85 c0 75 05 b8 f1
Aiee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!
In interrupt handler - not syncing


- -------------------------------------------------------------

Dmesg looks like this:

Linux version 2.4.0-test8 (root@c208e.mtalo.ton.tut.fi) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 SMP Sun Sep 24 11:15:38 EEST 2000
BIOS-provided physical RAM map:
 BIOS-e820: 000000000009fc00 @ 0000000000000000 (usable)
 BIOS-e820: 0000000000f00000 @ 0000000000100000 (usable)
 BIOS-e820: 0000000000040000 @ 00000000fffc0000 (reserved)
Scan SMP from c0000000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f0000 for 65536 bytes.
Scan SMP from c009fc00 for 4096 bytes.
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
mapped APIC to ffffe000 (00045000)
Kernel command line: auto BOOT_IMAGE=linuxu ro root=301 ether=5,0x380,eth0 ether=9,0xfc00,eth1 ethe
Initializing CPU#0
Detected 99387394 Hz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 198.25 BogoMIPS
Memory: 13992k/16384k available (1159k kernel code, 2004k reserved, 87k data, 212k init, 0k highmem)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
Checking 'hlt' instruction... OK.
Intel Pentium with F0 0F bug - workaround enabled.
POSIX conformance testing by UNIFIX
CPU0: Intel Pentium 75 - 200 stepping 05
per-CPU timeslice cutoff: 155.55 usecs.
SMP motherboard not detected. Using dummy APIC emulation.
Setting commenced=1, go go go
PCI: PCI BIOS revision 2.10 entry at 0xfd481, last bus=0
PCI: Using configuration type 1
PCI: Probing PCI hardware
Limiting direct PCI/PCI transfers.
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
NET4: Ethernet Bridge 008 for NET4.0
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
Initializing RT netlink socket
Starting kswapd v1.7
parport0: PC-style at 0x378 [PCSPP]
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX: IDE controller on PCI bus 00 dev 38
PIIX: chipset revision 2
PIIX: not 100% native mode: will probe irqs later
PIIX: neither IDE port enabled (BIOS)
PIIX: IDE controller on PCI bus 00 dev 39
PIIX: chipset revision 2
PIIX: not 100% native mode: will probe irqs later
keyboard: Timeout - AT keyboard not present?
keyboard: Timeout - AT keyboard not present?
hda: ST3850A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 1661184 sectors (851 MB) w/120KiB Cache, CHS=824/32/63
Partition check:
 hda: [PTBL] [103/255/63] hda1 hda2 < hda5 >
FDC 0 is a National Semiconductor PC87306
ne.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov)
NE*000 ethercard probe at 0x380: 00 50 4e 01 71 cf
eth0: NE2000 found at 0x380, using IRQ 5.
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
8139too Fast Ethernet driver 0.9.8 loaded
eth1: RealTek RTL8139 Fast Ethernet board found at 0xfffbf800, IRQ 10
eth1:   Chip is 'RTL-8139B'
eth1:   MAC address 00:48:54:6c:74:d3.
eth2: RealTek RTL8139 Fast Ethernet board found at 0xfffbfc00, IRQ 9
eth2:   Chip is 'RTL-8139B'
eth2:   MAC address 00:48:54:6c:7f:8a.
ip_tables: (c)2000 Netfilter core team
NET4: Ethernet Bridge 008 for NET4.0
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 212k freed
Adding Swap: 56188k swap-space (priority -1)
device eth1 entered promiscuous mode
device eth2 entered promiscuous mode
eth1: Promiscuous mode enabled.
eth1: Promiscuous mode enabled.
eth1: Promiscuous mode enabled.
eth2: Promiscuous mode enabled.
eth2: Promiscuous mode enabled.
eth2: Promiscuous mode enabled.
br0: port 2(eth2) entering listening state
br0: port 1(eth1) entering listening state
eth1: Setting full-duplex based on MII #32 link partner ability of 41e1.
br0: port 2(eth2) entering learning state
br0: port 1(eth1) entering learning state
br0: port 2(eth2) entering forwarding state
br0: topology change detected, propagating
br0: port 1(eth1) entering forwarding state
br0: topology change detected, propagating

- -------------------------------------------------------------

And this is my network script:

#!/bin/sh

brctl addbr br0
brctl addif br0 eth1
brctl addif br0 eth2

ifconfig eth1 0.0.0.0
ifconfig eth2 0.0.0.0
ifconfig br0 193.166.90.234

route add -host 193.166.90.201 br0
route add -host 193.166.90.229 br0

arp -i eth0 -s 193.166.90.201 00:50:4E:01:71:CF pub
arp -i eth0 -s 193.166.90.229 00:50:4E:01:71:CF pub








------- End of Forwarded Message


From owner-netdev@oss.sgi.com Mon Sep 25 04:21:24 2000
Received:  by oss.sgi.com id <S42329AbQIYLVO>;
	Mon, 25 Sep 2000 04:21:14 -0700
Received: from isis.its.uow.edu.au ([130.130.68.21]:15865 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42229AbQIYLVA>;
	Mon, 25 Sep 2000 04:21:00 -0700
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 WAA21894;
	Mon, 25 Sep 2000 22:20:37 +1100 (EST)
Message-ID: <39CF3574.24137A4A@uow.edu.au>
Date:   Mon, 25 Sep 2000 22:22:28 +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:     Ilkka Oksanen <ilkka@c208b.mtalo.ton.tut.fi>
CC:     netdev@oss.sgi.com
Subject: Re: 2.4.0-test8: BUG at skbuff.c:93!
References: <20000925083729.4581.qmail@c208b.mtalo.ton.tut.fi>
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
Content-Length: 292
Lines: 11

Ilkka Oksanen wrote:
> 
>  I have machine that is router and bridge.
>  With 2.4.0-test8 kernel it will crash
>  10-20 minutes after boot. Is this bug
>  in kernel?
> ...
> 8139too Fast Ethernet driver 0.9.8 loaded

8139too.c in test8 had a few problems.  You'll need to use a later
version.

From owner-netdev@oss.sgi.com Mon Sep 25 13:27:27 2000
Received:  by oss.sgi.com id <S42259AbQIYU1H>;
	Mon, 25 Sep 2000 13:27:07 -0700
Received: from kogge.hanse.de ([192.76.134.17]:44804 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S42201AbQIYU0n>;
	Mon, 25 Sep 2000 13:26:43 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id WAA10659;
	Mon, 25 Sep 2000 22:30:02 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id OAA12285;
	Sun, 24 Sep 2000 14:19:30 +0200
To:     jamal <hadi@cyberus.ca>
cc:     netdev@oss.sgi.com
Subject: Re: Giving priority to messages
References: <Pine.GSO.4.20.0009192227570.5716-100000@shell.cyberus.ca>
From:   Henner Eisen <eis@baty.hanse.de>
Date:   24 Sep 2000 14:19:30 +0200
In-Reply-To: jamal's message of "Tue, 19 Sep 2000 22:34:54 -0400 (EDT)"
Message-ID: <ouog1edlt9.fsf@baty.hanse.de>
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
Content-Length: 805
Lines: 19


Dear Jamal,

>>>>> "jamal" == jamal  <hadi@cyberus.ca> writes:

    jamal> The Tulip, for example, can have its DMA buffers stashed in
    jamal> a linked list instead of a ring structure.  Maybe not the
    jamal> most efficient scheme but could you could play with
    jamal> priority queueing structures/algorithms for the DMA buffers
    jamal> in this case and for example stick a higher priority packet

keep in mind (see our last thread) that some protocols require
packet ordering to be preserverved. As long the packet scheduler is the
only instance which can possibly re-order packets, such protocols can
take appropriate actions such that the packet schedulers won´t
perform re-ordering. If you had additional re-ordering inside the driver,
things would become even more complictated.

Henner

From owner-netdev@oss.sgi.com Mon Sep 25 13:28:17 2000
Received:  by oss.sgi.com id <S42261AbQIYU2H>;
	Mon, 25 Sep 2000 13:28:07 -0700
Received: from kogge.hanse.de ([192.76.134.17]:45316 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S42201AbQIYU1x>;
	Mon, 25 Sep 2000 13:27:53 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id WAA10998;
	Mon, 25 Sep 2000 22:31:15 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id UAA15049;
	Mon, 25 Sep 2000 20:37:16 +0200
To:     Donald Becker <becker@scyld.com>
cc:     netdev@oss.sgi.com
Subject: Re: Giving priority to messages
References: <Pine.LNX.4.10.10009192217060.1031-100000@vaio.greennet>
From:   Henner Eisen <eis@baty.hanse.de>
Date:   25 Sep 2000 20:37:15 +0200
In-Reply-To: Donald Becker's message of "Tue, 19 Sep 2000 22:25:36 -0400 (EDT)"
Message-ID: <ouem28e2sk.fsf@baty.hanse.de>
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
Content-Length: 749
Lines: 18


Hi,
>>>>> "Donald" == Donald Becker <becker@scyld.com> writes:

    Donald> This is one of the reasons for drivers to keep their Tx
    Donald> queues to a reasonable length.  Two years ago an
    Donald> almost-always-sufficient Tx queue length was between 6 and
    Donald> 10, so most of my bus-master drivers use a queue length of
    Donald> 10.  Ten 1500 byte packets at 10Mbps is still not too
    Donald> long, but ten 60 byte packets (approx. 96 byte periods on
    Donald> the wire) isn't very long at 100Mbps.

Would it make sense to use the data size (the accumulated
skb->len of the sk_buffs in a packet scheduler´s queue) instead of the
current tx queue length (number of sk_buffs) for mesuring the packet
scheduler´s queues?

Henner

From owner-netdev@oss.sgi.com Mon Sep 25 13:29:37 2000
Received:  by oss.sgi.com id <S42278AbQIYU31>;
	Mon, 25 Sep 2000 13:29:27 -0700
Received: from kogge.hanse.de ([192.76.134.17]:46340 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S42201AbQIYU3J>;
	Mon, 25 Sep 2000 13:29:09 -0700
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id WAA11003;
	Mon, 25 Sep 2000 22:32:25 +0200 (CEST)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id UAA15074;
	Mon, 25 Sep 2000 20:56:01 +0200
Date:   Mon, 25 Sep 2000 20:56:01 +0200
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200009251856.UAA15074@baty.hanse.de>
To:     hadi@cyberus.ca
CC:     davem@redhat.com, kuznet@ms2.inr.ac.ru, Robert.Olsson@data.slu.se,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com, becker@scyld.com
In-reply-to: <Pine.GSO.4.20.0009192133350.5716-100000@shell.cyberus.ca>
	(message from jamal on Tue, 19 Sep 2000 22:05:23 -0400 (EDT))
Subject: Re: [PATCH/RFC] (long) network interface changes
References:  <Pine.GSO.4.20.0009192133350.5716-100000@shell.cyberus.ca>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1561
Lines: 34

>>>>> "jamal" == jamal  <hadi@cyberus.ca> writes:
    >>  Nice. I think such a kind of fair input queueing would be an
    >> important features because that allows to offer a highly
    >> reliable netif() to slow links which are slow, but inefficient
    >> to handle congestion (like X.25 LAPB datalink
    >> protocol). Network interfaces could trade reliablilty for
    >> speed.
    >> 

    jamal> So i would prefer to leave this turned off. Infact i was
    jamal> hoping to take it off for the final code submission. If you
    jamal> insist, it could be left there and enabled during

No, I don´t insist. This was just some brain-storming ;).

[...]

    jamal> IPV4 as well. In the case of V6 and V4 it is called
    jamal> ECN. causing quiet a bit of havoc right now ;-> I can see
    jamal> the netif_rx() feedback clearly fitting in the 'receive
    jamal> busy/not-ready' details you talked about earlier. I dont
    jamal> see the CN fit clearly.  Maybe one way is to set the Frame
    jamal> Relay FECN bit after you return from netif_rx()? callbacks?
    jamal> nah, too complicated...

I think setting CN bits appropriatlely is the task of the upper
layer protocol anyway. The only thing is that the upper layers need
to know whether the input queue is congested. Maybe the netif_rx() code
could set an skb->rx_congested bit when it delivers packets to the
upper layer while the backlog queue is in congested state. (Maybe not
really necessary, the upper layer could also query the congestion state
by atomic_read(&netdev_dropping)).

Henner

From owner-netdev@oss.sgi.com Mon Sep 25 14:46:48 2000
Received:  by oss.sgi.com id <S42281AbQIYVqh>;
	Mon, 25 Sep 2000 14:46:37 -0700
Received: from lsne-cable-1-p21.vtxnet.ch ([212.147.5.21]:48395 "EHLO
        almesberger.net") by oss.sgi.com with ESMTP id <S42201AbQIYVqW>;
	Mon, 25 Sep 2000 14:46:22 -0700
Received: (from almesber@localhost)
	by almesberger.net (8.9.3/8.9.3) id XAA23262;
	Mon, 25 Sep 2000 23:42:14 +0200
Date:   Mon, 25 Sep 2000 23:42:13 +0200
From:   Werner Almesberger <Werner.Almesberger@epfl.ch>
To:     =?iso-8859-1?Q?Ram=F3n_Ag=FCero?= <ramon@tlmat.unican.es>
Cc:     netdev@oss.sgi.com
Subject: Re: IP checksum calculation
Message-ID: <20000925234213.A23224@almesberger.net>
References: <002801c022e5$6a4a8e20$1bba90c1@tlmat.unican.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <002801c022e5$6a4a8e20$1bba90c1@tlmat.unican.es>; from ramon@tlmat.unican.es on Wed, Sep 20, 2000 at 11:30:23AM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 521
Lines: 13

Ramón Agüero wrote:
>     I've developped a module that gets IP_packets, and changes their TOS
> field, then I call the ip_fast_csum in order to change its checksum.

Better yet, do what we do in linux/include/net/dsfield.h:ipv4_change_dsfield
in recent 2.3 or 2.4 test kernels.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

From owner-netdev@oss.sgi.com Mon Sep 25 17:11:09 2000
Received:  by oss.sgi.com id <S42309AbQIZAK7>;
	Mon, 25 Sep 2000 17:10:59 -0700
Received: from battlejitney.wdhq.scyld.com ([216.254.93.178]:18172 "EHLO convert rfc822-to-8bit
        vaio.greennet") by oss.sgi.com with ESMTP id <S42201AbQIZAKe>;
	Mon, 25 Sep 2000 17:10:34 -0700
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id UAA01222;
	Mon, 25 Sep 2000 20:12:34 -0400
Date:   Mon, 25 Sep 2000 20:12:34 -0400 (EDT)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     Henner Eisen <eis@baty.hanse.de>
cc:     netdev@oss.sgi.com
Subject: Re: Giving priority to messages
In-Reply-To: <ouem28e2sk.fsf@baty.hanse.de>
Message-ID: <Pine.LNX.4.10.10009251956390.1031-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
Content-Length: 1527
Lines: 32

On 25 Sep 2000, Henner Eisen wrote:
> >>>>> "Donald" == Donald Becker <becker@scyld.com> writes:
> 
>     Donald> This is one of the reasons for drivers to keep their Tx
>     Donald> queues to a reasonable length.  Two years ago an
>     Donald> almost-always-sufficient Tx queue length was between 6 and
>     Donald> 10, so most of my bus-master drivers use a queue length of
>     Donald> 10.  Ten 1500 byte packets at 10Mbps is still not too
>     Donald> long, but ten 60 byte packets (approx. 96 byte periods on
>     Donald> the wire) isn't very long at 100Mbps.
> 
> Would it make sense to use the data size (the accumulated
> skb->len of the sk_buffs in a packet scheduler´s queue) instead of the
> current tx queue length (number of sk_buffs) for mesuring the packet
> scheduler´s queues?

The data size frequently isn't a better metric:
  - On a busy half duplex network your outbound queue delay is a primarily
  function of the number of packets, not the size of those packets.
  - Is it really better for your "high priority" packet to be waiting behind
    50 tinygrams rather than only 4 large packets?

There might be a "have times changed?" issue here:
  Are most high performance networks switched?  Probably yes.
  Does switching (full duplex) change the queue metric?  Perhaps..
  Will Ethernet flow control change this back?  Probably yes.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf-II Cluster Distribution
Annapolis MD 21403


From owner-netdev@oss.sgi.com Mon Sep 25 18:38:29 2000
Received:  by oss.sgi.com id <S42283AbQIZBiK>;
	Mon, 25 Sep 2000 18:38:10 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:47316 "EHLO cyberus.ca") convert rfc822-to-8bit
	by oss.sgi.com with ESMTP id <S42201AbQIZBhc>;
	Mon, 25 Sep 2000 18:37:32 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id VAA10395;
	Mon, 25 Sep 2000 21:37:02 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id VAA18869;
	Mon, 25 Sep 2000 21:37:02 -0400 (EDT)
Date:   Mon, 25 Sep 2000 21:37:02 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Henner Eisen <eis@baty.hanse.de>
cc:     netdev@oss.sgi.com
Subject: Re: Giving priority to messages
In-Reply-To: <ouog1edlt9.fsf@baty.hanse.de>
Message-ID: <Pine.GSO.4.20.0009252132040.18843-100000@shell.cyberus.ca>
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
Content-Length: 727
Lines: 20


Henner,

On 24 Sep 2000, Henner Eisen wrote:

> keep in mind (see our last thread) that some protocols require
> packet ordering to be preserverved. As long the packet scheduler is the
> only instance which can possibly re-order packets, such protocols can
> take appropriate actions such that the packet schedulers won´t
> perform re-ordering. If you had additional re-ordering inside the driver,
> things would become even more complictated.

Actually, this is not re-ordering per-se. This would be done _per-flow_ 
and not with packets within the same flow.
i.e certain flows are more important than others and would skip FIFO queue
rules. But Donald pointed some issues with the scheme which i agree with.

cheers,
jamal


From owner-netdev@oss.sgi.com Mon Sep 25 18:57:19 2000
Received:  by oss.sgi.com id <S42350AbQIZB5A>;
	Mon, 25 Sep 2000 18:57:00 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:42715 "EHLO cyberus.ca") convert rfc822-to-8bit
	by oss.sgi.com with ESMTP id <S42201AbQIZB43>;
	Mon, 25 Sep 2000 18:56:29 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id VAA17309;
	Mon, 25 Sep 2000 21:55:57 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id VAA18897;
	Mon, 25 Sep 2000 21:55:57 -0400 (EDT)
Date:   Mon, 25 Sep 2000 21:55:57 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Henner Eisen <eis@baty.hanse.de>
cc:     davem@redhat.com, kuznet@ms2.inr.ac.ru, Robert.Olsson@data.slu.se,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com, becker@scyld.com
Subject: Re: [PATCH/RFC] (long) network interface changes
In-Reply-To: <200009251856.UAA15074@baty.hanse.de>
Message-ID: <Pine.GSO.4.20.0009252137160.18843-100000@shell.cyberus.ca>
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
Content-Length: 2074
Lines: 48



On Mon, 25 Sep 2000, Henner Eisen wrote:

> >>>>> "jamal" == jamal  <hadi@cyberus.ca> writes:
>     jamal> So i would prefer to leave this turned off. Infact i was
>     jamal> hoping to take it off for the final code submission. If you
>     jamal> insist, it could be left there and enabled during
> 
> No, I don´t insist. This was just some brain-storming ;).
> 

I'll just leave it in but disable it. Davem may choose to remove it.
It is the cheapest solution so far that has been experimented with.
Rusty had some interesting ideas on this as well ...

> I think setting CN bits appropriatlely is the task of the upper
> layer protocol anyway. The only thing is that the upper layers need
> to know whether the input queue is congested. Maybe the netif_rx() code
> could set an skb->rx_congested bit when it delivers packets to the
> upper layer while the backlog queue is in congested state. (Maybe not
> really necessary, the upper layer could also query the congestion state
> by atomic_read(&netdev_dropping)).

Interesting and quiet applicable to Frame Relay, for example; what do you
see other apps/protos using it for? Would TCP for example delay ACKs or
delay delivery of data? 
Actually, the more i think about it i realize that the rx_congested mark
might not be an accurate reflection of the situation when the skb gets to
the protocol/app. It will depend on when the rx softirq gets scheduled by
which time the information might not be accurate anymore.
It will probably also not make much sense in SMP (where one congested CPU
might not necessarily mean the rest are congested).

BTW, I checked the return values of the protocols which you had
concerns with and i believe there are not reflective of the
situation and there are a few semantical issues
eg ip_rcv()
on error returns 0. 0 is generally refered to as 'success' in other parts
of the code.
the good news is that no-code cares about/checks these return values.

I'll submit the current patch and maybe later submit another where the
protocols use things like NET_RX_SUCCESS etc

cheers,
jamal


From owner-netdev@oss.sgi.com Mon Sep 25 19:22:39 2000
Received:  by oss.sgi.com id <S42362AbQIZCW3>;
	Mon, 25 Sep 2000 19:22:29 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:52196 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42351AbQIZCV5>;
	Mon, 25 Sep 2000 19:21:57 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id WAA25734;
	Mon, 25 Sep 2000 22:20:35 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id WAA18954;
	Mon, 25 Sep 2000 22:20:36 -0400 (EDT)
Date:   Mon, 25 Sep 2000 22:20:36 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     davem@redhat.com
cc:     kuznet@ms2.inr.ac.ru, Robert.Olsson@data.slu.se,
        linux-kernel@vger.kernel.org, Henner Eisen <eis@baty.hanse.de>,
        netdev@oss.sgi.com, becker@scyld.com
Subject: [PATCH: Final ] WAS (Re: [PATCH/RFC] (long) network interface changes
In-Reply-To: <Pine.GSO.4.20.0009252137160.18843-100000@shell.cyberus.ca>
Message-ID: <Pine.GSO.4.20.0009252212460.18941-200000@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1804928587-969934836=:18941"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 12523
Lines: 240

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---559023410-1804928587-969934836=:18941
Content-Type: TEXT/PLAIN; charset=US-ASCII


Dave,

Final patch with feedback from Henner to change the naming convention of
the return codes. Clean it up, polish it, junk it etc.

I'd like also to send you a large patch or a series of patches to use the
NET_RX_* codes by the protocols. eg patch:

--------------------------------------------------------
--- ip_input.c	2000/09/23 12:48:56	1.1
+++ ip_input.c	2000/09/23 12:52:52
@@ -341,7 +341,7 @@
 
 		skb = skb_cow(skb, skb_headroom(skb));
 		if (skb == NULL)
-			return 0;
+			return NET_RX_DROP;
 		iph = skb->nh.iph;
 
 		skb->ip_summed = 0;
@@ -372,7 +372,7 @@
 	IP_INC_STATS_BH(IpInHdrErrors);
 drop:
         kfree_skb(skb);
-        return(0);
+        return NET_RX_DROP;
 }
 
 /*
@@ -429,6 +429,6 @@
 drop:
         kfree_skb(skb);
 out:
-        return(0);
+        return NET_RX_DROP;
 }
 
------------------------------------------------------

I realize nobody is using those codes but they would be useful and will
enforce consistency.

cheers,
jamal

---559023410-1804928587-969934836=:18941
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=FF-patch-test8
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.20.0009252220360.18941@shell.cyberus.ca>
Content-Description: 
Content-Disposition: attachment; filename=FF-patch-test8

LS0tIGxpbnV4L25ldC9jb3JlL2Rldi5jLm9yaWcJVGh1IFNlcCAgNyAxMToz
MjowMSAyMDAwDQorKysgbGludXgvbmV0L2NvcmUvZGV2LmMJVHVlIFNlcCAx
MiAyMDowMjoyMCAyMDAwDQpAQCAtNTksNiArNTksOCBAQA0KICAqCVBhdWwg
UnVzdHkgUnVzc2VsbAk6CVNJT0NTSUZOQU1FDQogICogICAgICAgICAgICAg
IFBla2thIFJpaWtvbmVuICA6CU5ldGRldiBib290LXRpbWUgc2V0dGluZ3Mg
Y29kZQ0KICAqICAgICAgICAgICAgICBBbmRyZXcgTW9ydG9uICAgOiAgICAg
ICBNYWtlIHVucmVnaXN0ZXJfbmV0ZGV2aWNlIHdhaXQgaW5kZWZpbml0ZWx5
IG9uIGRldi0+cmVmY250DQorICogCQlKIEhhZGkgU2FsaW0JOgktIEJhY2ts
b2cgcXVldWUgc2FtcGxpbmcNCisgKgkJCQkgICAgICAgIC0gbmV0aWZfcngo
KSBmZWVkYmFjawkNCiAgKi8NCiANCiAjaW5jbHVkZSA8YXNtL3VhY2Nlc3Mu
aD4NCkBAIC05Nyw2ICs5OSw5IEBADQogZXh0ZXJuIGludCBwbGlwX2luaXQo
dm9pZCk7DQogI2VuZGlmDQogDQorLyoNCisjZGVmaW5lIFJBTkRfTElFIDEN
CisqLw0KIE5FVF9QUk9GSUxFX0RFRklORShkZXZfcXVldWVfeG1pdCkNCiBO
RVRfUFJPRklMRV9ERUZJTkUoc29mdG5ldF9wcm9jZXNzKQ0KIA0KQEAgLTEz
Myw2ICsxMzgsMTEgQEANCiBzdGF0aWMgc3RydWN0IHBhY2tldF90eXBlICpw
dHlwZV9iYXNlWzE2XTsJCS8qIDE2IHdheSBoYXNoZWQgbGlzdCAqLw0KIHN0
YXRpYyBzdHJ1Y3QgcGFja2V0X3R5cGUgKnB0eXBlX2FsbCA9IE5VTEw7CQkv
KiBUYXBzICovDQogDQorI2lmZGVmIG9mZmxpbmVfc2FtcGxlDQorc3RhdGlj
IHZvaWQgc2FtcGxlX3F1ZXVlKHVuc2lnbmVkIGxvbmcgZHVtbXkpOw0KK3N0
YXRpYyBzdHJ1Y3QgdGltZXJfbGlzdCBzYW1wX3RpbWVyID0geyB7IE5VTEws
IE5VTEwgfSwgMCwgMCwgJnNhbXBsZV9xdWV1ZSB9Ow0KKyNlbmRpZg0KKw0K
IC8qDQogICoJT3VyIG5vdGlmaWVyIGxpc3QNCiAgKi8NCkBAIC05NTEsMTIg
Kzk2MSwyNSBAQA0KICAgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0qLw0K
IA0KIGludCBuZXRkZXZfbWF4X2JhY2tsb2cgPSAzMDA7DQorLyogdGhlc2Ug
bnVtYmVycyBhcmUgc2VsZWN0ZWQgYmFzZWQgb24gaW50dWl0aW9uIGFuZCBz
b21lDQorZXhwZXJpbWVudGF0aW9tLCBpZiB5b3UgaGF2ZSBtb3JlIHNjaWVu
dGlmaWMgd2F5IG9mIGRvaW5nIHRoaXMNCitwbGVhc2UgZ28gYWhlYWQgYW5k
IGZpeCB0aGluZ3MNCisqLw0KK2ludCBub19jb25nX3RocmVzaD0xMDsNCitp
bnQgbm9fY29uZz0yMDsNCitpbnQgbG9fY29uZz0xMDA7DQoraW50IG1vZF9j
b25nPTI5MDsNCisNCisNCiANCiBzdHJ1Y3QgbmV0aWZfcnhfc3RhdHMgbmV0
ZGV2X3J4X3N0YXRbTlJfQ1BVU107DQogDQogDQogI2lmZGVmIENPTkZJR19O
RVRfSFdfRkxPV0NPTlRST0wNCisvKg0KIHN0YXRpYyBhdG9taWNfdCBuZXRk
ZXZfZHJvcHBpbmcgPSBBVE9NSUNfSU5JVCgwKTsNCisqLw0KK2F0b21pY190
IG5ldGRldl9kcm9wcGluZyA9IEFUT01JQ19JTklUKDApOw0KIHN0YXRpYyB1
bnNpZ25lZCBsb25nIG5ldGRldl9mY19tYXNrID0gMTsNCiB1bnNpZ25lZCBs
b25nIG5ldGRldl9mY194b2ZmID0gMDsNCiBzcGlubG9ja190IG5ldGRldl9m
Y19sb2NrID0gU1BJTl9MT0NLX1VOTE9DS0VEOw0KQEAgLTEwMTQsNiArMTAz
Nyw1NiBAQA0KIH0NCiAjZW5kaWYNCiANCitzdGF0aWMgdm9pZCBnZXRfc2Ft
cGxlX3N0YXRzKGludCBjcHUpDQorew0KKyNpZmRlZiBSQU5EX0xJRQ0KKwl1
bnNpZ25lZCBsb25nIHJkOw0KKwlpbnQgcnE7DQorI2VuZGlmDQorCWludCBi
bG9nPXNvZnRuZXRfZGF0YVtjcHVdLmlucHV0X3BrdF9xdWV1ZS5xbGVuOw0K
KwlpbnQgYXZnX2Jsb2c9c29mdG5ldF9kYXRhW2NwdV0uYXZnX2Jsb2c7DQor
DQorCWF2Z19ibG9nPShhdmdfYmxvZyA+PiAxKSsgKGJsb2c+PjEpOw0KKw0K
KwlpZiAoYXZnX2Jsb2cgPiBtb2RfY29uZykgew0KKy8qICBhYm92ZSBtb2Rl
cmF0ZSBjb25nZXN0aW9uIGxldmVscyAqLw0KKwkJc29mdG5ldF9kYXRhW2Nw
dV0uY25nX2xldmVsPSBORVRfUlhfQ05fSElHSDsNCisjaWZkZWYgUkFORF9M
SUUNCisJCXJkPW5ldF9yYW5kb20oKTsNCisJCXJxPXJkJSBuZXRkZXZfbWF4
X2JhY2tsb2c7DQorCQlpZiAocnEgPCBhdmdfYmxvZykgLyogdW5sdWNreSBi
YXN0YXJkICovDQorCQkJc29mdG5ldF9kYXRhW2NwdV0uY25nX2xldmVsPU5F
VF9SWF9EUk9QOw0KKyNlbmRpZg0KKwl9IGVsc2UgaWYgKGF2Z19ibG9nID4g
bG9fY29uZykgew0KKwkJc29mdG5ldF9kYXRhW2NwdV0uY25nX2xldmVsPSBO
RVRfUlhfQ05fTU9EOw0KKyNpZmRlZiBSQU5EX0xJRQ0KKwkJcmQ9bmV0X3Jh
bmRvbSgpOw0KKwkJcnE9cmQlIG5ldGRldl9tYXhfYmFja2xvZzsNCisJCQlp
ZiAocnEgPCBhdmdfYmxvZykgLyogdW5sdWNreSBiYXN0YXJkICovDQorCQkJ
CXNvZnRuZXRfZGF0YVtjcHVdLmNuZ19sZXZlbD1ORVRfUlhfQ05fSElHSDsN
CisjZW5kaWYNCisJfSBlbHNlIGlmIChhdmdfYmxvZyA+IG5vX2NvbmcpIA0K
KwkJc29mdG5ldF9kYXRhW2NwdV0uY25nX2xldmVsPSBORVRfUlhfQ05fTE9X
Ow0KKwllbHNlICAvKiBubyBjb25nZXN0aW9uICovDQorCQlzb2Z0bmV0X2Rh
dGFbY3B1XS5jbmdfbGV2ZWw9TkVUX1JYX1NVQ0NFU1M7DQorDQorCXNvZnRu
ZXRfZGF0YVtjcHVdLmF2Z19ibG9nPWF2Z19ibG9nOw0KKw0KK30NCisNCisj
aWZkZWYgb2ZmbGluZV9zYW1wDQorc3RhdGljIHZvaWQgc2FtcGxlX3F1ZXVl
KHVuc2lnbmVkIGxvbmcgZHVtbXkpDQorew0KKy8qIDEwIG1zIDByIDFtcyAt
LSBpIGRvbnQgY2FyZSAtLSBKSFMgKi8NCisJaW50IG5leHRfdGljaz0xOw0K
KwlpbnQgY3B1PXNtcF9wcm9jZXNzb3JfaWQoKTsNCisJZ2V0X3NhbXBsZV9z
dGF0cyhjcHUpOw0KKwluZXh0X3RpY2srPWppZmZpZXM7DQorCW1vZF90aW1l
cigmc2FtcF90aW1lciwgbmV4dF90aWNrKTsNCit9DQorI2VuZGlmDQorDQor
DQogLyoqDQogICoJbmV0aWZfcngJLQlwb3N0IGJ1ZmZlciB0byB0aGUgbmV0
d29yayBjb2RlDQogICoJQHNrYjogYnVmZmVyIHRvIHBvc3QNCkBAIC0xMDIy
LDkgKzEwOTUsMTggQEANCiAgKgl0aGUgdXBwZXIgKHByb3RvY29sKSBsZXZl
bHMgdG8gcHJvY2Vzcy4gIEl0IGFsd2F5cyBzdWNjZWVkcy4gVGhlIGJ1ZmZl
cg0KICAqCW1heSBiZSBkcm9wcGVkIGR1cmluZyBwcm9jZXNzaW5nIGZvciBj
b25nZXN0aW9uIGNvbnRyb2wgb3IgYnkgdGhlIA0KICAqCXByb3RvY29sIGxh
eWVycy4NCisgKiAgICAgIA0KKyAqCXJldHVybiB2YWx1ZXM6DQorICoJTkVU
X1JYX1NVQ0NFU1MJKG5vIGNvbmdlc3Rpb24pICAgICAgICAgICANCisgKglO
RVRfUlhfQ05fTE9XICAgICAobG93IGNvbmdlc3Rpb24pIA0KKyAqCU5FVF9S
WF9DTl9NT0QgICAgIChtb2RlcmF0ZSBjb25nZXN0aW9uKQ0KKyAqCU5FVF9S
WF9DTl9ISUdIICAgIChoaWdoIGNvbmdlc3Rpb24pIA0KKyAqCU5FVF9SWF9E
Uk9QICAgIChwYWNrZXQgd2FzIGRyb3BwZWQpDQorICogICAgICANCisgKiAg
ICAgIA0KICAqLw0KIA0KLXZvaWQgbmV0aWZfcngoc3RydWN0IHNrX2J1ZmYg
KnNrYikNCitpbnQgbmV0aWZfcngoc3RydWN0IHNrX2J1ZmYgKnNrYikNCiB7
DQogCWludCB0aGlzX2NwdSA9IHNtcF9wcm9jZXNzb3JfaWQoKTsNCiAJc3Ry
dWN0IHNvZnRuZXRfZGF0YSAqcXVldWU7DQpAQCAtMTA0Myw2ICsxMTI1LDcg
QEANCiAJbmV0ZGV2X3J4X3N0YXRbdGhpc19jcHVdLnRvdGFsKys7DQogCWlm
IChxdWV1ZS0+aW5wdXRfcGt0X3F1ZXVlLnFsZW4gPD0gbmV0ZGV2X21heF9i
YWNrbG9nKSB7DQogCQlpZiAocXVldWUtPmlucHV0X3BrdF9xdWV1ZS5xbGVu
KSB7DQorDQogCQkJaWYgKHF1ZXVlLT50aHJvdHRsZSkNCiAJCQkJZ290byBk
cm9wOw0KIA0KQEAgLTEwNTQsMTEgKzExMzcsMTYgQEANCiAJCQlfX3NrYl9x
dWV1ZV90YWlsKCZxdWV1ZS0+aW5wdXRfcGt0X3F1ZXVlLHNrYik7DQogCQkJ
X19jcHVfcmFpc2Vfc29mdGlycSh0aGlzX2NwdSwgTkVUX1JYX1NPRlRJUlEp
Ow0KIAkJCWxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsNCi0JCQlyZXR1cm47
DQorI2lmbmRlZiBvZmZsaW5lX3NhbXANCisJCQlnZXRfc2FtcGxlX3N0YXRz
KHRoaXNfY3B1KTsNCisjZW5kaWYNCisJCQlyZXR1cm4gc29mdG5ldF9kYXRh
W3RoaXNfY3B1XS5jbmdfbGV2ZWw7DQorDQogCQl9DQogDQogCQlpZiAocXVl
dWUtPnRocm90dGxlKSB7DQogCQkJcXVldWUtPnRocm90dGxlID0gMDsNCisN
CiAjaWZkZWYgQ09ORklHX05FVF9IV19GTE9XQ09OVFJPTA0KIAkJCWlmIChh
dG9taWNfZGVjX2FuZF90ZXN0KCZuZXRkZXZfZHJvcHBpbmcpKQ0KIAkJCQlu
ZXRkZXZfd2FrZXVwKCk7DQpAQCAtMTA4MCw2ICsxMTY4LDggQEANCiAJbG9j
YWxfaXJxX3Jlc3RvcmUoZmxhZ3MpOw0KIA0KIAlrZnJlZV9za2Ioc2tiKTsN
CisJcmV0dXJuIE5FVF9SWF9EUk9QOw0KKw0KIH0NCiANCiAvKiBEZWxpdmVy
IHNrYiB0byBhbiBvbGQgcHJvdG9jb2wsIHdoaWNoIGlzIG5vdCB0aHJlYWRl
ZCB3ZWxsDQpAQCAtMTI5MiwxMiArMTM4MiwyOCBAQA0KIA0KIAkJaWYgKGJ1
Z2RldC0tIDwgMCB8fCBqaWZmaWVzIC0gc3RhcnRfdGltZSA+IDEpDQogCQkJ
Z290byBzb2Z0bmV0X2JyZWFrOw0KKw0KKy8qIA0KKyovDQorI2lmZGVmIENP
TkZJR19ORVRfSFdfRkxPV0NPTlRST0wNCisJaWYgKHF1ZXVlLT50aHJvdHRs
ZSAmJiBxdWV1ZS0+aW5wdXRfcGt0X3F1ZXVlLnFsZW4gPCBub19jb25nX3Ro
cmVzaCApIHsNCisJCWlmIChhdG9taWNfZGVjX2FuZF90ZXN0KCZuZXRkZXZf
ZHJvcHBpbmcpKSAgew0KKwkJCXF1ZXVlLT50aHJvdHRsZSA9IDA7DQorCQkJ
bmV0ZGV2X3dha2V1cCgpOw0KKwkJCWdvdG8gc29mdG5ldF9icmVhazsNCisJ
CX0NCisNCisJfQ0KKyNlbmRpZg0KKw0KKw0KIAl9DQogCWJyX3JlYWRfdW5s
b2NrKEJSX05FVFBST1RPX0xPQ0spOw0KIA0KIAlsb2NhbF9pcnFfZGlzYWJs
ZSgpOw0KIAlpZiAocXVldWUtPnRocm90dGxlKSB7DQogCQlxdWV1ZS0+dGhy
b3R0bGUgPSAwOw0KKw0KICNpZmRlZiBDT05GSUdfTkVUX0hXX0ZMT1dDT05U
Uk9MDQogCQlpZiAoYXRvbWljX2RlY19hbmRfdGVzdCgmbmV0ZGV2X2Ryb3Bw
aW5nKSkNCiAJCQluZXRkZXZfd2FrZXVwKCk7DQpAQCAtMjQxOCw2ICsyNTI0
LDcgQEANCiBpbnQgX19pbml0IG5ldF9kZXZfaW5pdCh2b2lkKQ0KIHsNCiAJ
c3RydWN0IG5ldF9kZXZpY2UgKmRldiwgKipkcDsNCisNCiAJaW50IGk7DQog
DQogI2lmZGVmIENPTkZJR19ORVRfU0NIRUQNCkBAIC0yNDM0LDYgKzI1NDEs
OCBAQA0KIAkJcXVldWUgPSAmc29mdG5ldF9kYXRhW2ldOw0KIAkJc2tiX3F1
ZXVlX2hlYWRfaW5pdCgmcXVldWUtPmlucHV0X3BrdF9xdWV1ZSk7DQogCQlx
dWV1ZS0+dGhyb3R0bGUgPSAwOw0KKwkJcXVldWUtPmNuZ19sZXZlbCA9IDA7
DQorCQlxdWV1ZS0+YXZnX2Jsb2cgPSAxMDsgLyogYXJiaXRyYXJ5IG5vbi16
ZXJvICovDQogCQlxdWV1ZS0+Y29tcGxldGlvbl9xdWV1ZSA9IE5VTEw7DQog
CX0NCiAJDQpAQCAtMjQ0Miw2ICsyNTUxLDEyIEBADQogCU5FVF9QUk9GSUxF
X1JFR0lTVEVSKGRldl9xdWV1ZV94bWl0KTsNCiAJTkVUX1BST0ZJTEVfUkVH
SVNURVIoc29mdG5ldF9wcm9jZXNzKTsNCiAjZW5kaWYNCisNCisjaWZkZWYg
b2ZmbGluZV9zYW1wDQorCXNhbXBfdGltZXIuZXhwaXJlcz1qaWZmaWVzKygx
MCAqIEhaKTsNCisJYWRkX3RpbWVyKCZzYW1wX3RpbWVyKTsNCisjZW5kaWYN
CisNCiAJLyoNCiAJICoJQWRkIHRoZSBkZXZpY2VzLg0KIAkgKglJZiB0aGUg
Y2FsbCB0byBkZXYtPmluaXQgZmFpbHMsIHRoZSBkZXYgaXMgcmVtb3ZlZA0K
QEAgLTI0OTksNiArMjYxNCw3IEBADQogI2lmZGVmIENPTkZJR19QUk9DX0ZT
DQogCXByb2NfbmV0X2NyZWF0ZSgiZGV2IiwgMCwgZGV2X2dldF9pbmZvKTsN
CiAJY3JlYXRlX3Byb2NfcmVhZF9lbnRyeSgibmV0L3NvZnRuZXRfc3RhdCIs
IDAsIDAsIGRldl9wcm9jX3N0YXRzLCBOVUxMKTsNCisNCiAjaWZkZWYgV0lS
RUxFU1NfRVhUDQogCXByb2NfbmV0X2NyZWF0ZSgid2lyZWxlc3MiLCAwLCBk
ZXZfZ2V0X3dpcmVsZXNzX2luZm8pOw0KICNlbmRpZgkvKiBXSVJFTEVTU19F
WFQgKi8NCi0tLSBsaW51eC9pbmNsdWRlL2xpbnV4L25ldGRldmljZS5oLm9y
aWcJRnJpIFNlcCAgOCAxNTo1Mzo1MyAyMDAwDQorKysgbGludXgvaW5jbHVk
ZS9saW51eC9uZXRkZXZpY2UuaAlUdWUgU2VwIDEyIDIwOjAxOjI1IDIwMDAN
CkBAIC00Nyw2ICs0NywxMyBAQA0KIAkJCQkJICAgKFRDIHVzZSBvbmx5IC0g
ZGV2X3F1ZXVlX3htaXQNCiAJCQkJCSAgIHJldHVybnMgdGhpcyBhcyBORVRf
WE1JVF9TVUNDRVNTKSAqLw0KIA0KKy8qIEJhY2tsb2cgY29uZ2VzdGlvbiBs
ZXZlbHMgKi8NCisjZGVmaW5lIE5FVF9SWF9TVUNDRVNTCQkwICAgLyoga2Vl
cCAnZW0gY29taW5nLCBiYWJ5ICovDQorI2RlZmluZSBORVRfUlhfQ05fTE9X
CQkxICAgLyogc3Rvcm0gYWxlcnQsIGp1c3QgaW4gY2FzZSAqLw0KKyNkZWZp
bmUgTkVUX1JYX0NOX01PRAkJMiAgIC8qIFN0b3JtIG9uIGl0cyB3YXkhICov
DQorI2RlZmluZSBORVRfUlhfQ05fSElHSAkJNSAgIC8qIFRoZSBzdG9ybSBp
cyBoZXJlICovDQorI2RlZmluZSBORVRfUlhfRFJPUAkJLTEgIC8qIHBhY2tl
dCBkcm9wcGVkICovDQorDQogI2RlZmluZSBuZXRfeG1pdF9lcnJubyhlKQko
KGUpICE9IE5FVF9YTUlUX0NOID8gLUVOT0JVRlMgOiAwKQ0KIA0KICNlbmRp
Zg0KQEAgLTQ0MCw2ICs0NDcsOCBAQA0KIHN0cnVjdCBzb2Z0bmV0X2RhdGEN
CiB7DQogCWludAkJCXRocm90dGxlOw0KKwlpbnQJCQljbmdfbGV2ZWw7DQor
CWludAkJCWF2Z19ibG9nOw0KIAlzdHJ1Y3Qgc2tfYnVmZl9oZWFkCWlucHV0
X3BrdF9xdWV1ZTsNCiAJc3RydWN0IG5ldF9kZXZpY2UJKm91dHB1dF9xdWV1
ZTsNCiAJc3RydWN0IHNrX2J1ZmYJCSpjb21wbGV0aW9uX3F1ZXVlOw0KQEAg
LTUyNiw3ICs1MzUsNyBAQA0KIA0KIGV4dGVybiB2b2lkCQluZXRfY2FsbF9y
eF9hdG9taWModm9pZCAoKmZuKSh2b2lkKSk7DQogI2RlZmluZSBIQVZFX05F
VElGX1JYIDENCi1leHRlcm4gdm9pZAkJbmV0aWZfcngoc3RydWN0IHNrX2J1
ZmYgKnNrYik7DQorZXh0ZXJuIGludAkJbmV0aWZfcngoc3RydWN0IHNrX2J1
ZmYgKnNrYik7DQogZXh0ZXJuIGludAkJZGV2X2lvY3RsKHVuc2lnbmVkIGlu
dCBjbWQsIHZvaWQgKik7DQogZXh0ZXJuIGludAkJZGV2X2NoYW5nZV9mbGFn
cyhzdHJ1Y3QgbmV0X2RldmljZSAqLCB1bnNpZ25lZCk7DQogZXh0ZXJuIHZv
aWQJCWRldl9xdWV1ZV94bWl0X25pdChzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBz
dHJ1Y3QgbmV0X2RldmljZSAqZGV2KTsNCkBAIC02MjgsNiArNjM3LDcgQEAN
CiBleHRlcm4gdm9pZAkJbmV0ZGV2X3VucmVnaXN0ZXJfZmMoaW50IGJpdCk7
DQogZXh0ZXJuIGludAkJbmV0ZGV2X21heF9iYWNrbG9nOw0KIGV4dGVybiB1
bnNpZ25lZCBsb25nCW5ldGRldl9mY194b2ZmOw0KK2V4dGVybiBhdG9taWNf
dCBuZXRkZXZfZHJvcHBpbmc7DQogZXh0ZXJuIGludAkJbmV0ZGV2X3NldF9t
YXN0ZXIoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IG5ldF9kZXZp
Y2UgKm1hc3Rlcik7DQogI2lmZGVmIENPTkZJR19ORVRfRkFTVFJPVVRFDQog
ZXh0ZXJuIGludAkJbmV0ZGV2X2Zhc3Ryb3V0ZTsNCi0tLSAvdXNyL3NyYy9s
aW51eC9uZXQvbmV0c3ltcy5jCTIwMDAvMDkvMTYgMjM6MDA6MzMJMS4xDQor
KysgL3Vzci9zcmMvbGludXgvbmV0L25ldHN5bXMuYwkyMDAwLzA5LzE2IDIz
OjAxOjI4DQpAQCAtNDkwLDYgKzQ5MCw3IEBADQogRVhQT1JUX1NZTUJPTChk
ZXZfaW9jdGwpOw0KIEVYUE9SVF9TWU1CT0woZGV2X3F1ZXVlX3htaXQpOw0K
ICNpZmRlZiBDT05GSUdfTkVUX0hXX0ZMT1dDT05UUk9MDQorRVhQT1JUX1NZ
TUJPTChuZXRkZXZfZHJvcHBpbmcpOw0KIEVYUE9SVF9TWU1CT0wobmV0ZGV2
X3JlZ2lzdGVyX2ZjKTsNCiBFWFBPUlRfU1lNQk9MKG5ldGRldl91bnJlZ2lz
dGVyX2ZjKTsNCiBFWFBPUlRfU1lNQk9MKG5ldGRldl9mY194b2ZmKTsNCg==
---559023410-1804928587-969934836=:18941--

From owner-netdev@oss.sgi.com Mon Sep 25 19:45:09 2000
Received:  by oss.sgi.com id <S42351AbQIZCot>;
	Mon, 25 Sep 2000 19:44:49 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:53996 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42299AbQIZCo1>;
	Mon, 25 Sep 2000 19:44:27 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id WAA03156;
	Mon, 25 Sep 2000 22:43:27 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id WAA19019;
	Mon, 25 Sep 2000 22:43:28 -0400 (EDT)
Date:   Mon, 25 Sep 2000 22:43:28 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     davem@redhat.com
cc:     kuznet@ms2.inr.ac.ru, Robert.Olsson@data.slu.se,
        linux-kernel@vger.kernel.org, Henner Eisen <eis@baty.hanse.de>,
        netdev@oss.sgi.com, becker@scyld.com
Subject: Re: [PATCH: Final ] WAS (Re: [PATCH/RFC] (long) network interface
 changes
In-Reply-To: <Pine.GSO.4.20.0009252212460.18941-200000@shell.cyberus.ca>
Message-ID: <Pine.GSO.4.20.0009252242310.19017-200000@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-969936208=:19017"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 2077
Lines: 46

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---559023410-851401618-969936208=:19017
Content-Type: TEXT/PLAIN; charset=US-ASCII


shit, i forgot this small addendum to the patch.
Attached.

cheers,
jamal


---559023410-851401618-969936208=:19017
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=patchlet
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.20.0009252243280.19017@shell.cyberus.ca>
Content-Description: 
Content-Disposition: attachment; filename=patchlet

LS0tIGxpbnV4L25ldC9jb3JlL3N5c2N0bF9uZXRfY29yZS5jLm9yaWcJV2Vk
IEZlYiAgOSAyMzowODowOSAyMDAwDQorKysgbGludXgvbmV0L2NvcmUvc3lz
Y3RsX25ldF9jb3JlLmMJVHVlIFNlcCAxMiAyMDowNjoxNSAyMDAwDQpAQCAt
MTIsNiArMTIsMTAgQEANCiAjaWZkZWYgQ09ORklHX1NZU0NUTA0KIA0KIGV4
dGVybiBpbnQgbmV0ZGV2X21heF9iYWNrbG9nOw0KK2V4dGVybiBpbnQgbm9f
Y29uZ190aHJlc2g7DQorZXh0ZXJuIGludCBub19jb25nOw0KK2V4dGVybiBp
bnQgbG9fY29uZzsNCitleHRlcm4gaW50IG1vZF9jb25nOw0KIGV4dGVybiBp
bnQgbmV0ZGV2X2Zhc3Ryb3V0ZTsNCiBleHRlcm4gaW50IG5ldF9tc2dfY29z
dDsNCiBleHRlcm4gaW50IG5ldF9tc2dfYnVyc3Q7DQpAQCAtNDEsNiArNDUs
MTggQEANCiAJICZwcm9jX2RvaW50dmVjfSwNCiAJe05FVF9DT1JFX01BWF9C
QUNLTE9HLCAibmV0ZGV2X21heF9iYWNrbG9nIiwNCiAJICZuZXRkZXZfbWF4
X2JhY2tsb2csIHNpemVvZihpbnQpLCAwNjQ0LCBOVUxMLA0KKwkgJnByb2Nf
ZG9pbnR2ZWN9LA0KKwl7TkVUX0NPUkVfTUFYX0JBQ0tMT0csICJub19jb25n
X3RocmVzaCIsDQorCSAmbm9fY29uZywgc2l6ZW9mKGludCksIDA2NDQsIE5V
TEwsDQorCSAmcHJvY19kb2ludHZlY30sDQorCXtORVRfQ09SRV9NQVhfQkFD
S0xPRywgIm5vX2NvbmciLA0KKwkgJm5vX2NvbmcsIHNpemVvZihpbnQpLCAw
NjQ0LCBOVUxMLA0KKwkgJnByb2NfZG9pbnR2ZWN9LA0KKwl7TkVUX0NPUkVf
TUFYX0JBQ0tMT0csICJsb19jb25nIiwNCisJICZsb19jb25nLCBzaXplb2Yo
aW50KSwgMDY0NCwgTlVMTCwNCisJICZwcm9jX2RvaW50dmVjfSwNCisJe05F
VF9DT1JFX01BWF9CQUNLTE9HLCAibW9kX2NvbmciLA0KKwkgJm1vZF9jb25n
LCBzaXplb2YoaW50KSwgMDY0NCwgTlVMTCwNCiAJICZwcm9jX2RvaW50dmVj
fSwNCiAjaWZkZWYgQ09ORklHX05FVF9GQVNUUk9VVEUNCiAJe05FVF9DT1JF
X0ZBU1RST1VURSwgIm5ldGRldl9mYXN0cm91dGUiLA0K
---559023410-851401618-969936208=:19017--

From owner-netdev@oss.sgi.com Tue Sep 26 00:46:42 2000
Received:  by oss.sgi.com id <S42287AbQIZHqW>;
	Tue, 26 Sep 2000 00:46:22 -0700
Received: from mail.zmailer.org ([194.252.70.162]:18195 "EHLO zmailer.org")
	by oss.sgi.com with ESMTP id <S42281AbQIZHpz>;
	Tue, 26 Sep 2000 00:45:55 -0700
Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@zmailer.org))
	by mail.zmailer.org id <S378572AbQIZHpL>;
	Tue, 26 Sep 2000 10:45:11 +0300
Date:	Tue, 26 Sep 2000 10:45:11 +0300
From:	Matti Aarnio <matti.aarnio@zmailer.org>
To:	jamal <hadi@cyberus.ca>
Cc:	davem@redhat.com, kuznet@ms2.inr.ac.ru, Robert.Olsson@data.slu.se,
        linux-kernel@vger.kernel.org, Henner Eisen <eis@baty.hanse.de>,
        netdev@oss.sgi.com, becker@scyld.com
Subject: Re: [PATCH: Final ] WAS (Re: [PATCH/RFC] (long) network interface changes
Message-ID: <20000926104511.A11669@mea-ext.zmailer.org>
References: <Pine.GSO.4.20.0009252137160.18843-100000@shell.cyberus.ca> <Pine.GSO.4.20.0009252212460.18941-200000@shell.cyberus.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.20.0009252212460.18941-200000@shell.cyberus.ca>; from hadi@cyberus.ca on Mon, Sep 25, 2000 at 10:20:36PM -0400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 237
Lines: 11

On Mon, Sep 25, 2000 at 10:20:36PM -0400, jamal wrote:
> To:	davem@redhat.com
> 
> Dave,

   Just FYI.  DaveM is on vacation until about 1st of October.
   He doesn't have email reading tools at the beach.

   Be patient.

/Matti Aarnio

From owner-netdev@oss.sgi.com Tue Sep 26 11:56:26 2000
Received:  by oss.sgi.com id <S42275AbQIZS4H>;
	Tue, 26 Sep 2000 11:56:07 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:54537 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42276AbQIZSzl>;
	Tue, 26 Sep 2000 11:55:41 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA08684; Tue, 26 Sep 2000 22:50:37 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200009261850.WAA08684@ms2.inr.ac.ru>
Subject: Re: [project6-devel] (fwd) Re: scope id question
To:     mauro@ferrara.linux.it (Mauro Tortonesi)
Date:   Tue, 26 Sep 2000 22:50:37 +0400 (MSK DST)
Cc:     project6-devel@ferrara.linux.it, netdev@oss.sgi.com
In-Reply-To: <Pine.LNX.4.21.0009262024440.618-100000@trantor.ferrara.linux.it> from "Mauro Tortonesi" at Sep 26, 0 08:30:54 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 216
Lines: 13

Hello!

> e.g. suppose a user enters:
> 
> finger @fe80::EUI64ADDR
> 
> how can the finger client connect to that address (in linux)? 

No doubts, it will fail.

This address does not define any unique host.

Alexey

From owner-netdev@oss.sgi.com Tue Sep 26 12:06:56 2000
Received:  by oss.sgi.com id <S42283AbQIZTGg>;
	Tue, 26 Sep 2000 12:06:36 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:58377 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42243AbQIZTGO>;
	Tue, 26 Sep 2000 12:06:14 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA08717; Tue, 26 Sep 2000 22:58:52 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200009261858.WAA08717@ms2.inr.ac.ru>
Subject: Re: icmpv6 error handling code in linux kernel
To:     mauro@ferrara.linux.it (Mauro Tortonesi)
Date:   Tue, 26 Sep 2000 22:58:52 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <Pine.LNX.4.21.0009262038130.618-200000@trantor.ferrara.linux.it> from "Mauro Tortonesi" at Sep 26, 0 08:40:31 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 237
Lines: 11

Hello!

> different purpose. here is a note from alexei kuznetsov (linux kernel 
> developer):

AK is Andi Kleen.

But I agree on each of the words written there.
It is not a "bug", but rather offending mud in the RFC.

Alexey Kuznetsov

From owner-netdev@oss.sgi.com Tue Sep 26 12:08:26 2000
Received:  by oss.sgi.com id <S42278AbQIZTIR>;
	Tue, 26 Sep 2000 12:08:17 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:59145 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42243AbQIZTIA>;
	Tue, 26 Sep 2000 12:08:00 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA08752; Tue, 26 Sep 2000 23:02:48 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200009261902.XAA08752@ms2.inr.ac.ru>
Subject: Re: [project6-devel] (fwd) Re: scope id question
To:     mauro@ferrara.linux.it (Mauro Tortonesi)
Date:   Tue, 26 Sep 2000 23:02:48 +0400 (MSK DST)
Cc:     project6-devel@ferrara.linux.it, netdev@oss.sgi.com
In-Reply-To: <Pine.LNX.4.21.0009262058450.945-100000@trantor.ferrara.linux.it> from "Mauro Tortonesi" at Sep 26, 0 09:00:15 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 182
Lines: 8

Hello!

> please forgive my dumbness, but i don't understand why. if it defines a
> unique-on-link interface, then it defines a unique-on-link host. or not?

On _what_ link?

Alexey

From owner-netdev@oss.sgi.com Tue Sep 26 12:16:16 2000
Received:  by oss.sgi.com id <S42302AbQIZTQH>;
	Tue, 26 Sep 2000 12:16:07 -0700
Received: from tyholt.uninett.no ([158.38.60.10]:61960 "EHLO tyholt.uninett.no")
	by oss.sgi.com with ESMTP id <S42287AbQIZTPw>;
	Tue, 26 Sep 2000 12:15:52 -0700
Received: from sverresborg.uninett.no (IDENT:root@sverresborg.uninett.no [158.38.60.92])
	by tyholt.uninett.no (8.9.3/8.9.3) with ESMTP id VAA04298;
	Tue, 26 Sep 2000 21:15:10 +0200
Received: (from venaas@localhost)
	by sverresborg.uninett.no (8.10.1/8.10.1) id e8QJJ4218259;
	Tue, 26 Sep 2000 21:19:04 +0200
Date:   Tue, 26 Sep 2000 21:19:03 +0200
From:   Stig Venaas <Stig.Venaas@uninett.no>
To:     project6-devel@ferrara.linux.it
Cc:     Mauro Tortonesi <mauro@ferrara.linux.it>, netdev@oss.sgi.com
Subject: Re: [project6-devel] (fwd) Re: scope id question
Message-ID: <20000926211903.A18254@sverresborg.uninett.no>
References: <Pine.LNX.4.21.0009262024440.618-100000@trantor.ferrara.linux.it> <200009261850.WAA08684@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200009261850.WAA08684@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Tue, Sep 26, 2000 at 10:50:37PM +0400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1134
Lines: 30

On Tue, Sep 26, 2000 at 10:50:37PM +0400, kuznet@ms2.inr.ac.ru wrote:
> Hello!
> 
> > e.g. suppose a user enters:
> > 
> > finger @fe80::EUI64ADDR
> > 
> > how can the finger client connect to that address (in linux)? 
> 
> No doubts, it will fail.
> 
> This address does not define any unique host.

The behavior is the same with KAME I think. A link local address is
only guaranteed to be unique on the link, the application could
perhaps do some tricks, if it sees only one interface besides lo it
could try to use that, or it could go through all the interfaces.
It's impossible to know which interface/link. You have the same
problem on hosts that are on the boundary between sites.

Actually it's reasonable that you have to supply the interface even
when using one of the hosts own link local addresses, there could be
a host on one of the other links with the same address.

There was quite intense discussions on this on the ipng list about
when the DC IETF was, November last year? You might check those, or
perhaps better, look at draft-ietf-ipngwg-scoping-arch-01.txt and
draft-ietf-ipngwg-scopedaddr-format-02.txt.

Stig

From owner-netdev@oss.sgi.com Wed Sep 27 02:25:43 2000
Received:  by oss.sgi.com id <S42302AbQI0JZd>;
	Wed, 27 Sep 2000 02:25:33 -0700
Received: from leonardo.telscom.ch ([193.247.121.34]:32773 "EHLO
        leonardo.telscom.ch") by oss.sgi.com with ESMTP id <S42278AbQI0JZP>;
	Wed, 27 Sep 2000 02:25:15 -0700
Received: from swetha ([193.247.121.46]) by leonardo.telscom.ch
          (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-0U10L2S100)
          with SMTP id AAA233 for <netdev@oss.sgi.com>;
          Wed, 27 Sep 2000 11:16:57 +0200
Message-ID: <00af01c02864$8cfb6460$2e79f7c1@lakshmi>
Reply-To: "Riccardo De Luca" <riccardo@telscom.ch>
From:   "Riccardo De Luca" <Riccardo.DeLuca@telscom.ch>
To:     <netdev@oss.sgi.com>
Subject: ipv6 header
Date:   Wed, 27 Sep 2000 11:22:35 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00A6_01C02875.3C1EA5A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1347
Lines: 43

This is a multi-part message in MIME format.

------=_NextPart_000_00A6_01C02875.3C1EA5A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear sirs,
=20
I wrote a program to access into the ipv6 header contents and I tried to =
change some values. Could you tell me how can I test if it works using =
RedHat linux 6.0 ?

Thank you
Riccardo

------=_NextPart_000_00A6_01C02875.3C1EA5A0
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.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dear sirs</FONT><FONT face=3DArial=20
size=3D2>,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I wrote a program to access into the =
ipv6 header=20
contents and I tried to change some values. Could you tell me how can I =
test if=20
it works using RedHat linux&nbsp;6.0 ?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Riccardo</FONT></DIV></BODY></HTML>

------=_NextPart_000_00A6_01C02875.3C1EA5A0--


From owner-netdev@oss.sgi.com Wed Sep 27 04:22:23 2000
Received:  by oss.sgi.com id <S42325AbQI0LWN>;
	Wed, 27 Sep 2000 04:22:13 -0700
Received: from ganymede.or.intel.com ([134.134.248.3]:23058 "EHLO
        ganymede.or.intel.com") by oss.sgi.com with ESMTP id <S42278AbQI0LVz>;
	Wed, 27 Sep 2000 04:21:55 -0700
Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id EAA11348
	for <netdev@oss.sgi.com>; Wed, 27 Sep 2000 04:21:48 -0700 (PDT)
Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 27 Sep 2000 11:21:48 0000 (GMT)
Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2650.21)
	id <T3NP3GT4>; Wed, 27 Sep 2000 04:21:46 -0700
Message-ID: <07E6E3B8C072D211AC4100A0C9C5758302B27035@hasmsx52.iil.intel.com>
From:   "Hen, Shmulik" <shmulik.hen@intel.com>
To:     "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>
Subject: FW: Q: network drivers interface changes
Date:   Wed, 27 Sep 2000 04:17:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 707
Lines: 27

Hello,

Is there a good source of information that describes the changes in network
driver interface between 2.2.x and 2.4.x kernels ?


	Thanks,
	Shmulik Hen      Software Engineer
	Linux Advanced Networking Services
	Intel Network Communications Group
	Jerusalem

-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] 
Sent: Wednesday, September 27, 2000 1:01 PM
To: shmulik.hen@intel.com
Subject: Re: Q: network drivers interface changes


> Is there a good source of information that describes the changes in
network
> driver interface between 2.2.x and 2.4.x kernels ?

Jamal wrote a sort of summary about it.  netdev@oss.sgi.com is the better
place to ask for networking stuff



From owner-netdev@oss.sgi.com Wed Sep 27 05:45:43 2000
Received:  by oss.sgi.com id <S42330AbQI0MpW>;
	Wed, 27 Sep 2000 05:45:22 -0700
Received: from isis.its.uow.edu.au ([130.130.68.21]:24465 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S42278AbQI0MpD>;
	Wed, 27 Sep 2000 05:45:03 -0700
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 XAA15952;
	Wed, 27 Sep 2000 23:44:50 +1100 (EST)
Message-ID: <39D1EC39.F5437156@uow.edu.au>
Date:   Wed, 27 Sep 2000 23:46:49 +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:     "Hen, Shmulik" <shmulik.hen@intel.com>
CC:     "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>
Subject: Re: FW: Q: network drivers interface changes
References: <07E6E3B8C072D211AC4100A0C9C5758302B27035@hasmsx52.iil.intel.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
Content-Length: 473
Lines: 16

"Hen, Shmulik" wrote:
> 
> Hello,
> 
> Is there a good source of information that describes the changes in network
> driver interface between 2.2.x and 2.4.x kernels ?

http://www.uwsg.iu.edu/hypermail/linux/kernel/0002.1/0408.html
http://lwn.net/2000/0217/a/softnet-howto.html

And if you're really patient, look for all the irritating questions I
asked in

http://oss.sgi.com/projects/netdev/archive/netdev.0003
and
http://oss.sgi.com/projects/netdev/archive/netdev.0004

From owner-netdev@oss.sgi.com Wed Sep 27 06:11:13 2000
Received:  by oss.sgi.com id <S42343AbQI0NLD>;
	Wed, 27 Sep 2000 06:11:03 -0700
Received: from teapot23.domain2.bigpond.com ([139.134.5.165]:62987 "HELO
        teapot23.domain2.bigpond.com") by oss.sgi.com with SMTP
	id <S42278AbQI0NKo>; Wed, 27 Sep 2000 06:10:44 -0700
Received: from localhost (localhost [127.0.0.1]) by teapot23.domain2.bigpond.com (NTMail 3.02.13) with ESMTP id va128383 for <netdev@oss.sgi.com>; Wed, 27 Sep 2000 23:06:56 +1000
Received: from EXIP-T-011-p-107-148.tmns.net.au ([139.134.107.148]) by mail2.bigpond.com (Claudes-Woozy-MailRouter V2.9b 3/3882973); 27 Sep 2000 23:06:55
Message-ID: <39C535BB.10BA75B2@telstra.com>
Date:   Mon, 18 Sep 2000 08:20:59 +1100
From:   Roger Venning <r.venning@telstra.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev@oss.sgi.com
Subject: 6to4 support
Content-Type: multipart/mixed;
 boundary="------------443FFB550026C1FF23FA280C"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 3477
Lines: 109

This is a multi-part message in MIME format.
--------------443FFB550026C1FF23FA280C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Greetings all,

attached is a patch to provide 6to4 support for Linux. This allows for connection to the mbone without statically configured tunnels.

6to4 provides a mechanism for IPv6 tunneling through IPv4 domains using IPv4 addresses embedded in site prefixes.

Further details can be found in on a webpage containing a description and configuration information at http://www.users.bigpond.com/r.venning/, or at http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4-07.txt

The patch is to sit.c, and simply provides another check in addition to the current support for compatibility mode addresses when the sit0 device has wildcard remote and local addresses.

A synopsis of configuration

IP=<insert global scope IP address belonging to your 6to4 gateway>
quads=`echo ${IP} | sed 's/\./ /g'`
prefix=`printf "2002:%x%x:%x%x\n" ${quads}`
ip link set sit0 up     # we want sit0 running in wildcard send/receive mode
ip addr add ${prefix}::1 dev sit0    # simplest case...
ip route add 2002::/16 dev sit0     # route to 6to4 land via sit0
ip route add ::/0 via ::131.107.65.121 # I use microsoft's 6to4 site
                                    # you might be able to use ipv6-router.cisco.com
                                    # point is, use somebody as gateway to 6bone

Other IPv6 hosts on the site can then proceed to use the global scope
prefix 2002:...:....::/48

cheers,

Roger.




--------------443FFB550026C1FF23FA280C
Content-Type: text/plain; charset=us-ascii;
 name="sit.c.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="sit.c.diff"

--- linux-2.4.0-test6clean/net/ipv6/sit.c	Sat Aug  5 11:18:49 2000
+++ linux-2.4.0-test6hacked/net/ipv6/sit.c	Mon Aug 28 08:43:49 2000
@@ -27,6 +27,7 @@
 #include <linux/netdevice.h>
 #include <linux/if_arp.h>
 #include <linux/icmp.h>
+#include <linux/inet.h>
 #include <asm/uaccess.h>
 #include <linux/init.h>
 #include <linux/netfilter_ipv4.h>
@@ -55,6 +56,7 @@
 
 #define HASH_SIZE  16
 #define HASH(addr) ((addr^(addr>>4))&0xF)
+#define SIXTO4PREF htons(0x2002)
 
 static int ipip6_fb_tunnel_init(struct net_device *dev);
 static int ipip6_tunnel_init(struct net_device *dev);
@@ -420,6 +422,28 @@
 	return ip_send(skb);
 }
 
+
+/* returns the embedded IPv4 address if the IPv6 address
+   comes from 6to4 (draft-ietf-ngtrans-6to4-06) addr space */
+static inline u32 try_6to4(struct in6_addr *v6dst) {
+	u32 dst = 0;
+	
+	if (*v6dst->s6_addr16 == SIXTO4PREF) {
+	        /* 6to4 v6 addr has 16 bits prefix, 32 v4addr, 16 SLA, ... */
+		memcpy(&dst, &v6dst->s6_addr16[1], sizeof(u32));
+		if (IN_MULTICAST(ntohl(dst)) || 
+		   (dst == htonl(INADDR_BROADCAST)) ||
+		   IN_LOOPBACK(ntohl(dst))) {
+			if (net_ratelimit())
+				printk("sit.c: 6to4 IPv6 dest. encoded naughty IPv4 dest. %s\n",
+				       in_ntoa(dst));
+			return 0;
+		}
+	}
+	return dst;
+}
+
+
 /*
  *	This function assumes it is being called from dev_queue_xmit()
  *	and that skb is filled properly by that function.
@@ -448,6 +472,12 @@
 
 	if (skb->protocol != __constant_htons(ETH_P_IPV6))
 		goto tx_error;
+
+	if (!dst) {
+		/* well we first check if they are using the SIT device
+		   in wildcard 6to4 send mode */
+		dst = try_6to4(&iph6->daddr);
+	}
 
 	if (!dst) {
 		struct neighbour *neigh = NULL;

--------------443FFB550026C1FF23FA280C--


From owner-netdev@oss.sgi.com Fri Sep 29 08:37:10 2000
Received:  by oss.sgi.com id <S42402AbQI2Pgu>;
	Fri, 29 Sep 2000 08:36:50 -0700
Received: from felix.convergence.de ([212.84.236.131]:51979 "EHLO
        convergence.de") by oss.sgi.com with ESMTP id <S42190AbQI2Pgg>;
	Fri, 29 Sep 2000 08:36:36 -0700
Received: (qmail 20444 invoked by uid 100); 29 Sep 2000 15:35:00 -0000
Date:   29 Sep 2000 15:35:00 -0000
Message-ID: <20000929153500.20443.qmail@convergence.de>
From:   leitner@convergence.de
To:     r.venning@telstra.com, netdev@oss.sgi.com
Subject: Re: 6to4 support
In-Reply-To: <39C535BB.10BA75B2@telstra.com>
References: <39C535BB.10BA75B2@telstra.com>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 285
Lines: 14

In local.linux-netdev, you wrote:
> IP=<insert global scope IP address belonging to your 6to4 gateway>
> quads=`echo ${IP} | sed 's/\./ /g'`
> prefix=`printf "2002:%x%x:%x%x\n" ${quads}`

This looks wrong to me.

Use

  prefix=`printf "2002:%x%02x:%x%02x\n" ${quads}`

instead.

Felix

From owner-netdev@oss.sgi.com Sat Sep 30 08:26:49 2000
Received:  by oss.sgi.com id <S42252AbQI3P0j>;
	Sat, 30 Sep 2000 08:26:39 -0700
Received: from natmail2.webmailer.de ([192.67.198.65]:45209 "EHLO
        post.webmailer.de") by oss.sgi.com with ESMTP id <S42232AbQI3P0P>;
	Sat, 30 Sep 2000 08:26:15 -0700
Received: from frog.athome (pec-104-19.tnt5.s2.uunet.de [149.225.104.19])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id RAA01845;
	Sat, 30 Sep 2000 17:26:11 +0200 (MET DST)
Received: from localhost (hgfelger@localhost)
	by frog.athome (8.9.3/8.9.3) with ESMTP id RAA00358;
	Sat, 30 Sep 2000 17:20:04 +0200
X-Authentication-Warning: frog.athome: hgfelger owned process doing -bs
Date:   Sat, 30 Sep 2000 17:19:58 +0200 (CEST)
From:   Hartwig Felger <hgfelger@hgfelger.de>
X-Sender: hgfelger@frog.athome
Reply-To: hgfelger@hgfelger.de
To:     Marc Boucher <marc@mbsi.ca>
cc:     Rusty Russell <rusty@linuxcare.com.au>,
        netfilter-devel@us4.samba.org, netdev@oss.sgi.com
Subject: Was: dsl masquerading over linux 2.4.0-test[78]pre... FTP is still
 no-go
In-Reply-To: <200009120327.e8C3RVg06232@opium.mbsi.ca>
Message-ID: <Pine.LNX.4.10.10009272352590.910-100000@frog.athome>
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
Content-Length: 2282
Lines: 66

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salut folks,
thanks for the TCP-MSS patch- /suppoert in iptables; it works nice with
http for me. I use the --clamp-mss-to-pmtu option. But now I found, that
ftp is still not working. I tryed it with ISDN and it worked. So it seems
to be something like the previous problem, we dicussed early september. As
I do not understand TCP's deeper sekrets, I need the help from you friends
;-)

Thanks for suggestion - you happy tester...
hartwig 

On Mon, 11 Sep 2000, Marc Boucher wrote:
> Hi Rusty,
> > In message <200009071814.e87IEfA06978@opium.mbsi.ca> you write:
> > > Rusty, what would you think of adding the missing hooks to the 'mangle'
> > > table; extending its purpose to general packet alteration, not just
> > > changing stuff that influences routing?
> > 
> > Yes; this would be a win.  Since it's generally a network hackers toy,
> > we should make it less restrictive.  But the code freeze means it will
> > remain a separate patch until 2.4.1 at least.
> 
> IMHO such a straightforward/low-risk change should go in right away.
> 
> Why not look at it as a "design bug-fix" rather than a feature addition?
> :-)
> 
> > Now: what priority should it be?  Does it matter?
> 
> You mean hook priority? I don't think it really matters in this case.
> 
> > > I am also considering implementing a --clamp-mss-to-mtu option to the
> > 
> > This would be excellent; even better to use the path mtu, so if
> > someone else has a lower MTU (causing the first TCP connection to
> > stall), the second one might succeed.
> 
> Ok, support for --clamp-mss-to-pmtu option has been implemented and
> checked-in; please review code changes.
> 
> Recommended usage is now:
> 
> iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
> 
> [but wouldn't it be neater with "-t mangle" ? :-)] 
> 
> Cheers,
> Marc

- - -- 
1024D/339FD693 Hartwig Felger <hgfelger@hgfelger.de>
Key fingerprint = FB2F 3EE9 345A D55B 6FF2  0EC1 F5B0 684F 339F D693
For the pulic keys, please visit my page.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE51gSj9bBoTzOf1pMRAvxsAKDhVu5lknawb2qkjp9bBabpphqpTwCePM85
ivhpaKo3++S0SKa9z+MUMrI=
=6kl+
-----END PGP SIGNATURE-----