Re: [RFC] Configuring synchronous interfaces in Linux
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
(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 |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
>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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
>Does 'ifconfig eth0 media xxx' wind up calling dev->set_config? Yes. p. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
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 |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
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/26/msg3.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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
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] [[] ] > ... > [mem_start ] [io_addr ] [irq ] [media ] 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
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] [[] ] ... [mem_start ] [io_addr ] [irq ] [media ] ... _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
[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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/