Hello,
For synchronous network interfaces, besides configuring network parameters
such as IP address, netmask, MTU, etc., the system should also configure
parameters specific to these sync i/f's, such as media (e.g V.35, X.21,
T1, E1), clock (internal or external, and value if int.), protocol (e.g
PPP, HDLC, Frame Relay), etc.
What I noticed was that each synchronous board in Linux provides a
different way of doing this, and it would be good for users to have a
single, standard interface (such as ifconfig) to do this type of
configuration. Maybe even patch ifconfig itself, I don't know ...
Questions:
- Is there any existing _standard_ interface to do that??
- If not, is there any existing _standard_ infrastructure (e.g. ioctls and
structures) so that I can write an application to do that over this
standard structure?
- If not, where would be the right place in the kernel to change in order
to implement such infrastructure?
I'm interested in implementing this, but I don't want to reinvent the
wheel (if such wheel exists ...).
Thanks in advance for your comments.
Later,
Ivan
[netdev Cced]
The Thu, Nov 30, 2000 at 11:16:52AM -0800, Ivan Passos wrote :
[...]
> For synchronous network interfaces, besides configuring network parameters
> such as IP address, netmask, MTU, etc., the system should also configure
> parameters specific to these sync i/f's, such as media (e.g V.35, X.21,
> T1, E1), clock (internal or external, and value if int.), protocol (e.g
> PPP, HDLC, Frame Relay), etc.
> What I noticed was that each synchronous board in Linux provides a
> different way of doing this, and it would be good for users to have a
> single, standard interface (such as ifconfig) to do this type of
> configuration. Maybe even patch ifconfig itself, I don't know ...
>
> Questions:
> - Is there any existing _standard_ interface to do that??
No.
> - If not, is there any existing _standard_ infrastructure (e.g. ioctls and
> structures) so that I can write an application to do that over this
> standard structure?
x25 does things like this:
#define SIOCX25GSUBSCRIP (SIOCPROTOPRIVATE + 0)
#define SIOCX25SSUBSCRIP (SIOCPROTOPRIVATE + 1)
...
Thus one could use private ioctl behind SIOCDEVPRIVATE and SIOCPROTOPRIVATE as
defined in include/linux/sockios.h. Something under /proc(/sys ?) is
possible too but I would ask for the policy that applies to /proc before
coding.
> - If not, where would be the right place in the kernel to change in order
> to implement such infrastructure?
net/* for the protocol handler.
include/linux/if_arp.h
include/linux/if_ether.h
Some place may be updated too:
net/lapb/*
net/x25/*
net/wanrouter
drivers/char/n_hdlc.c
drivers/net/wan/*
> I'm interested in implementing this, but I don't want to reinvent the
> wheel (if such wheel exists ...).
Ditto.
--
Ueimor
On Fri, Dec 01, 2000 at 10:01:24AM +0100, Francois romieu wrote:
> Questions:
> - Is there any existing _standard_ interface to do that??
No.
[...]
> I'm interested in implementing this, but I don't want to reinvent the
> wheel (if such wheel exists ...).
Ditto.
Actually; Ethernet badly needs something like this too. I would kill
to be able to do something like:
ifconfig eth0 speed 100 duplex full
o across different networks cards -- I've been thinking about it of
late as I had to battle with this earlier this week; depending on
what network card you use, you need different magic incarnations to
do the above.
A standard interface is really needed; unless anyone objects I may
look at drafting something up -- but it will require some input if it
is not to look completely Ethernet centric.
--cw
In article <[email protected]> you wrote:
> Actually; Ethernet badly needs something like this too. I would kill
> to be able to do something like:
> ifconfig eth0 speed 100 duplex full
> o across different networks cards -- I've been thinking about it of
> late as I had to battle with this earlier this week; depending on
> what network card you use, you need different magic incarnations to
> do the above.
> A standard interface is really needed; unless anyone objects I may
> look at drafting something up -- but it will require some input if it
> is not to look completely Ethernet centric.
For ethernet we have ethtool, recently changed from sparc only to
architecture independend.
Christoph
--
Always remember that you are unique. Just like everyone else.
Chris Wedgwood writes:
> Actually; Ethernet badly needs something like this too. I would kill
> to be able to do something like:
>
> ifconfig eth0 speed 100 duplex full
>
> o across different networks cards -- I've been thinking about it of
> late as I had to battle with this earlier this week; depending on
> what network card you use, you need different magic incarnations to
> do the above.
>
> A standard interface is really needed; unless anyone objects I may
> look at drafting something up -- but it will require some input if it
> is not to look completely Ethernet centric.
We already have a standard interface for this, but many drivers do not
support it. Its called "ifconfig eth0 media xxx":
bash-2.04# ifconfig --help
Usage:
ifconfig [-a] [-i] [-v] [-s] <interface> [[<AF>] <address>]
...
[mem_start <NN>] [io_addr <NN>] [irq <NN>] [media <type>]
...
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [email protected] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
Chris Wedgwood <[email protected]> ?crit :
[...]
> o across different networks cards -- I've been thinking about it of
> late as I had to battle with this earlier this week; depending on
> what network card you use, you need different magic incarnations to
> do the above.
>
> A standard interface is really needed; unless anyone objects I may
> look at drafting something up -- but it will require some input if it
> is not to look completely Ethernet centric.
Regarding the clocking issue, synchronous interfaces need to know wether
the signal is externally provided or internally generated. The latter
implies to set the frequency too.
--
Ueimor
> In article <[email protected]> you wrote:
> > Actually; Ethernet badly needs something like this too. I would kill
> > to be able to do something like:
>
> > ifconfig eth0 speed 100 duplex full
>
> > o across different networks cards -- I've been thinking about it of
> > late as I had to battle with this earlier this week; depending on
> > what network card you use, you need different magic incarnations to
> > do the above.
>
> > A standard interface is really needed; unless anyone objects I may
> > look at drafting something up -- but it will require some input if it
> > is not to look completely Ethernet centric.
>
> For ethernet we have ethtool, recently changed from sparc only to
> architecture independend.
It should be consistent with the wireless extentions (same goal)
Xav
Russell King <[email protected]> ?crit :
[...]
> We already have a standard interface for this, but many drivers do not
> support it. Its called "ifconfig eth0 media xxx":
>
> bash-2.04# ifconfig --help
> Usage:
> ifconfig [-a] [-i] [-v] [-s] <interface> [[<AF>] <address>]
> ...
> [mem_start <NN>] [io_addr <NN>] [irq <NN>] [media <type>]
Ok. Hmmm... If I want to do something like
'ifconfig scc0 media some_frequency up' as I hope to set scc0 as a DCE (or
ifconfig scc0 media auto up' for a DTE), I must teach ifconfig.c to
distinguish Ethernet and synchrone interface based on interface.type, right ?
--
Ueimor
On Fri, 1 Dec 2000, Chris Wedgwood wrote:
> Actually; Ethernet badly needs something like this too. I would kill
> to be able to do something like:
>
> ifconfig eth0 speed 100 duplex full
Even if you are thinking about Ethernet only, it's not easy to do it. Most
modern NICs have MII transceivers, where media setting is more or less
following a standard. All drivers written by Donald Becker and probably
everything derived from them support MII get/set operations from
user-space through ioctls, using mii-diag (from ftp.scyld.com).
But there are NICs which do not have MII transceivers and media
setting/selection is NIC-specific. Take a look at the media specific
module options for several drivers (e.g. 3c59x and tulip) and you'll see
what I'm talking about.
Moreover, with the proposed ifconfig interface, there is a problem: do you
want the media setting to be locked ? Quite a lot of NICs can do
NWAY autonegotiation or the driver can go through the available modes
trying to get one working. So if you say "I want to use this speed", do
you want to specifically use that speed or give it just as a starting
point for the driver which can decrease the speed in case it's not able to
get it ? (the example is Ethernet specific, but the ideea is not).
And finally (also Ethernet specific): some devices don't like forced
media settings when they support autonegotiation. Look at the tulip recent
archives for examples.
Sincerely,
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: [email protected]
In message <[email protected]>, Russell King wri
tes:
>We already have a standard interface for this, but many drivers do not
>support it. Its called "ifconfig eth0 media xxx":
The Ethtool interface is rather better.
p.
On Fri, 01 Dec 2000, Francois romieu wrote:
> [netdev Cced]
>
> The Thu, Nov 30, 2000 at 11:16:52AM -0800, Ivan Passos wrote :
> [...]
> > For synchronous network interfaces, besides configuring network parameters
> > such as IP address, netmask, MTU, etc., the system should also configure
> > parameters specific to these sync i/f's, such as media (e.g V.35, X.21,
> > T1, E1), clock (internal or external, and value if int.), protocol (e.g
> > PPP, HDLC, Frame Relay), etc.
> > What I noticed was that each synchronous board in Linux provides a
> > different way of doing this, and it would be good for users to have a
> > single, standard interface (such as ifconfig) to do this type of
> > configuration. Maybe even patch ifconfig itself, I don't know ...
> >
> > Questions:
> > - Is there any existing _standard_ interface to do that??
>
> No.
>
Humm... If I recall the thread about 802.1Q that happened in June on netdev,
(See the thread starting at
http://sloth.wcug.wwu.edu/lists/netdev/200006/msg00003.html ), and I add up
with what I read here, I think we would be due for a major rewrite of the Layer
2 akin to what Alexey did for Layer 3 in 2.2.
A lot of questions need to be answered like:
What is _really_ a net_device ? (Hardware card, interface to tag a L3 address
on, etc..)
Considering the following divisions that exist today:
- A hardware card (or let's say a chipset so that anything on a mobo count as
well) can have many physical ports. I will call them PHY.
- A PHY can use TDM or Wavelenght Multiplexing (including Lambdas on
GEthernet and 10 GEthernet fibers) or both ! to create physical channels.
I'll call them Channels.
- Each of these Channels may further on use logics in header to (possibly)
create virtual links (802.1Q, MPLS (?)) Let's call this top abstraction a
Link, that is, something that can receive a L3 address.
Consider as well that you want to maintain the actual funtionnality of the
kernel, including:
- Bridging.
- 802.1Q VLANing (with a patch from one of Gleb or Ben's Project)
- Bridging/802.1Q (Is this possible yet ?)
- Hooking a _lot_ of different L3 on top of L2 (including AplleTalk, etc)
- simple user tools like, ifconfig, and very powerful one, like ip.
How many abstractions are really desirable at Layer 2 in order to limit the
proliferation of tools linked to specific hardware?
--
Fran?ois Desloges
[email protected]
On Fri, 1 Dec 2000, Francois Romieu wrote:
> Russell King <[email protected]> ?crit :
> [...]
> > We already have a standard interface for this, but many drivers do not
> > support it. Its called "ifconfig eth0 media xxx":
Uhmmm, it's not a standard if "many drivers do not support it".
It is very easy to hack up code to handle one or two drivers.
But you shouldn't claim the problem is fixed until the approach is tested
with all of the driver.
Hey, I'll make it easy. Find an approach that fully handles only the Tulip
and 3c59x drivers, and that is consistent.
I'll start you out: the possible 100baseTx configurations for the 3c59x
driver are SYM transceiver, MII transceiver, and "NWay" transceiver. The
latter two may use autonegotiation, only speed autosensing, or a fixed
speed. The SYM transceiver version can do static speed sensing.
[[ Note static speed sensing on the 3c595 is potentially evil. The chip
must generate 100baseTx link beat while checking for 100baseTx link beat.
This commonly hoses a 10baseT repeater with constant collisions. So does
"auto speed" mean "check for 100baseTx link beat, even though I sense
10baseT" or "do the safe thing and stick with 10baseT". ]]
> Ok. Hmmm... If I want to do something like
> 'ifconfig scc0 media some_frequency up' as I hope to set scc0 as a DCE (or
> ifconfig scc0 media auto up' for a DTE), I must teach ifconfig.c to
> distinguish Ethernet and synchrone interface based on interface.type,
> right ?
Correct. And just speed isn't good enough for Ethernet. We have 1/10HPNA,
100base-Fx,Tx,T4.
We should not just give up.
My point is that the issue isn't a trivial one.
Media selection code is the most time consuming and error prone code in many
drivers. I would have avoiding doing that work if there had been an easy
answer.
Donald Becker [email protected]
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993
On Sat, Dec 02, 2000 at 11:09:35AM -0500, Donald Becker wrote:
On Fri, 1 Dec 2000, Francois Romieu wrote:
> Russell King <[email protected]> ?crit :
> [...]
> > We already have a standard interface for this, but many drivers do not
> > support it. Its called "ifconfig eth0 media xxx":
Uhmmm, it's not a standard if "many drivers do not support it".
It is very easy to hack up code to handle one or two drivers.
But you shouldn't claim the problem is fixed until the approach is tested
with all of the driver.
Hey, I'll make it easy. Find an approach that fully handles only the Tulip
and 3c59x drivers, and that is consistent.
Actually, I starteed work on adding this to the 3c59x code last
night; I am now a little dispondent though as it wasn't as simple as
I first thought it might be.
I am now wondering whether it make sense to break 3c59x into smaller
peices which hander fewer cards each; there soom to be many things
the driver knows about which probably don't relate to my needs.
--cw
On Sun, 3 Dec 2000, Chris Wedgwood wrote:
> > Russell King <[email protected]> ?crit :
> > [...]
> > > We already have a standard interface for this, but many drivers do not
> > > support it. Its called "ifconfig eth0 media xxx":
> Actually, I starteed work on adding this to the 3c59x code last
> night; I am now a little dispondent though as it wasn't as simple as
> I first thought it might be.
Does 'ifconfig eth0 media xxx' wind up calling dev->set_config?
If yes, my guess is correct, I think the proper solution is to:
* create a generic set_config, which does nothing but convert the calls'
semantics into ethtool semantics, and
* add ethtool support to the specific driver
And you might even go so far as to create a generic MII implementation
of ethtool support, so that existing drivers can simply plug in their
mdio_{read,write} functions to automatically get full ethtool support.
(disclaimer: this is a spur-of-the-moment thought, creating a generic
MII module for ethtool support may not be feasible)
drivers/net/sis900.c implements set_config, if you want an example..
Finally, if you want to just use ethtool directly, grab the SRPM and
install it on your system.
Jeff
On Sun, 3 Dec 2000, Chris Wedgwood wrote:
> On Sat, Dec 02, 2000 at 11:09:35AM -0500, Donald Becker wrote:
>
> Hey, I'll make it easy. Find an approach that fully handles only the Tulip
> and 3c59x drivers, and that is consistent.
>
> Actually, I starteed work on adding this to the 3c59x code last
> night; I am now a little dispondent though as it wasn't as simple as
> I first thought it might be.
>
> I am now wondering whether it make sense to break 3c59x into smaller
> peices which hander fewer cards each; there soom to be many things
> the driver knows about which probably don't relate to my needs.
It's certainly possible to break the driver up, but it will be even more of
a problem to maintain. Some of the complicated media selection code applies
to several generations. Splitting the driver to have a copy for each
generation means a lot of duplicated code, which quickly leads to version
skew.
The story usually goes like this:
Someone wants to experiment with a driver. It's always exciting to tweak
the code for the latest and greatest. But the driver has all of this
complicated stuff for other, usually older, card/kernel versions. So the
hacker tosses out the code, "simplifying" the driver. They then release the
"new and improved driver".
They have no CVS tree to maintain, no old driver or hardware versions to
keep track of. No one has been using the driver for years, and thus there
is no one screaming when their production machine stop working. All of the
people with problems are just referred to the guy who did the original
driver, who is still expected to be there when things break. They don't
realize they have just removed all of the excitement and motivation for they
guy who is doing all of the time consuming maintenance and testing work.
I don't mean to pick on 3Com, but the driver they released is a good
example. It supported only a tiny set of card types that 3Com was currently
selling, and only with the current kernel. It didn't support the previous
card types, the OEMed versions, or the older kernels. The assumption was
that my driver would exist to support those hard cases, but by handling the
easy 90% that 3Com would get most of the credit.
Donald Becker [email protected]
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993
Jeff Garzik writes:
> Does 'ifconfig eth0 media xxx' wind up calling dev->set_config?
Yes. See drivers/acorn/net/etherh.c for an(other) example driver
supporting 10baseT and 10base2.
> If yes, my guess is correct, I think the proper solution is to:
> * create a generic set_config, which does nothing but convert the calls'
> semantics into ethtool semantics, and
> * add ethtool support to the specific driver
Sounds logical.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [email protected] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
>Does 'ifconfig eth0 media xxx' wind up calling dev->set_config?
Yes.
p.
On Sat, 2 Dec 2000 13:07:29 -0600 (CST),
Jeff Garzik <[email protected]> wrote:
>If yes, my guess is correct, I think the proper solution is to:
>* create a generic set_config, which does nothing but convert the calls'
>semantics into ethtool semantics, and
>* add ethtool support to the specific driver
cc list trimmed.
If you go down this path, please add a standard performance monitoring
method to query the current capacity of an interface. It is frustrating
to report "eth0 is handling 1 Megabyte/second, but we cannot tell if
that is 90% (10BaseT) or 9% (100BaseT) utilization". We should report
capacity rather than speed because speed alone is not the controlling
factor, other things like half or full duplex affect the capacity.
Does it? At which point? To me it looks like it calls dev->do_ioctl
or am I missing something?
--cw
On Sat, Dec 02, 2000 at 08:02:00PM +0000, Philip Blundell wrote:
>Does 'ifconfig eth0 media xxx' wind up calling dev->set_config?
Yes.
p.
>Does it? At which point? To me it looks like it calls dev->do_ioctl
>or am I missing something?
It uses SIOCSIFMAP, which (I think) winds up in dev.c here:
case SIOCSIFMAP:
if (dev->set_config) {
if (!netif_device_present(dev))
return -ENODEV;
return dev->set_config(dev,&ifr->ifr_map);
}
return -EOPNOTSUPP;
p.
(CC list trimmed)
Philip Blundell writes:
> >Does it? At which point? To me it looks like it calls dev->do_ioctl
> >or am I missing something?
>
> It uses SIOCSIFMAP, which (I think) winds up in dev.c here:
>
> case SIOCSIFMAP:
> if (dev->set_config) {
> if (!netif_device_present(dev))
> return -ENODEV;
> return dev->set_config(dev,&ifr->ifr_map);
> }
> return -EOPNOTSUPP;
It definitely does end up there. However, the ethtool ioctls end up
in dev->do_ioctl.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [email protected] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
On Sun, 3 Dec 2000, Keith Owens wrote:
> If you go down this path, please add a standard performance monitoring
> method to query the current capacity of an interface.
> to report "eth0 is handling 1 Megabyte/second, but we cannot tell if
> that is 90% (10BaseT) or 9% (100BaseT) utilization". We should report
> capacity rather than speed because speed alone is not the controlling
> factor, other things like half or full duplex affect the capacity.
Well, ethtool interface supports reporting media selection as well as
[re]setting media setting. I dunno if we could report what capacity
an interface is handling without adding code to hot paths...
Jeff
On Sun, 3 Dec 2000 07:43:01 -0600 (CST),
Jeff Garzik <[email protected]> wrote:
>On Sun, 3 Dec 2000, Keith Owens wrote:
>> If you go down this path, please add a standard performance monitoring
>> method to query the current capacity of an interface.
>Well, ethtool interface supports reporting media selection as well as
>[re]setting media setting. I dunno if we could report what capacity
>an interface is handling without adding code to hot paths...
You calculate the capacity during ifconfig up or during speed change.
That is not on the hot path.
On Mon, 04 Dec 2000 07:29:10 +1100,
Keith Owens <[email protected]> wrote:
>On Sun, 3 Dec 2000 07:43:01 -0600 (CST),
>Jeff Garzik <[email protected]> wrote:
>>On Sun, 3 Dec 2000, Keith Owens wrote:
>>> If you go down this path, please add a standard performance monitoring
>>> method to query the current capacity of an interface.
>>Well, ethtool interface supports reporting media selection as well as
>>[re]setting media setting. I dunno if we could report what capacity
>>an interface is handling without adding code to hot paths...
>
>You calculate the capacity during ifconfig up or during speed change.
>That is not on the hot path.
Replying to my own mail, I just realised it was ambiguous. By "current
capacity" I mean the maximum capacity of the link based on the current
settings. We can get capacity _used_ from the byte counters, we do not
have a figure for maximum capacity.
On Sat, Dec 02, 2000 at 02:48:10PM -0500, Donald Becker wrote:
It's certainly possible to break the driver up, but it will be
even more of a problem to maintain. Some of the complicated
media selection code applies to several generations. Splitting
the driver to have a copy for each generation means a lot of
duplicated code, which quickly leads to version skew.
So how does someone, like me for example, try to cleanly add support
for something like ethtool when the only hardware they have is say
3c920 and they could care less about the rest?
The best thing I can see to do is to restructure the driver as is and
try to get common paths for things like media setting and remove the
module parameter hacks we now have; that way it should be possible to
add ethtool support that works for everything...
... how does that sound?
--cw
P.S. Also, since only _two_ drivers actually support ethtool (hme and
acenic) is everyone 100% happy they want this API? Surely now is
the best time to invite discussion and promote ideas if people
have requirements that ethtool can't satisfy?