* Re: [patch 3/3] bridge: netlink interface for link management
From: jamal @ 2006-05-24 18:11 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, David Miller
In-Reply-To: <20060524171348.001557000@localhost.localdomain>
Very nice.
On Wed, 2006-24-05 at 10:12 -0700, Stephen Hemminger wrote:
> plain text document attachment (bridge-netlink.patch)
> Add basic netlink support to the Ethernet bridge. Including:
> * dump interfaces in bridges
> * monitor link status changes
> * change state of bridge port
> +static int br_fill_ifinfo(struct sk_buff *skb, const struct net_bridge_port *port,
> + u32 pid, u32 seq, int event, unsigned int flags)
> +{
> + const struct net_bridge *br = port->br;
> + const struct net_device *dev = port->dev;
> + struct ifinfomsg *r;
> + struct nlmsghdr *nlh;
> + unsigned char *b = skb->tail;
> + u32 mtu = dev->mtu;
> + u8 operstate = netif_running(dev) ? dev->operstate : IF_OPER_DOWN;
> + u8 portstate = port->state;
> +
> + pr_debug("br_fill_info event %d port %s master %s\n",
> + event, dev->name, br->dev->name);
> +
> + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*r), flags);
> + r = NLMSG_DATA(nlh);
> + r->ifi_family = AF_BRIDGE;
> + r->__ifi_pad = 0;
> + r->ifi_type = dev->type;
> + r->ifi_index = dev->ifindex;
> + r->ifi_flags = dev_get_flags(dev);
> + r->ifi_change = 0;
> +
> + RTA_PUT(skb, IFLA_IFNAME, strlen(dev->name)+1, dev->name);
> +
> + RTA_PUT(skb, IFLA_MASTER, sizeof(int), &br->dev->ifindex);
> +
> + if (dev->addr_len)
> + RTA_PUT(skb, IFLA_ADDRESS, dev->addr_len, dev->dev_addr);
> +
> + RTA_PUT(skb, IFLA_MTU, sizeof(mtu), &mtu);
> + if (dev->ifindex != dev->iflink)
> + RTA_PUT(skb, IFLA_LINK, sizeof(int), &dev->iflink);
> +
> +
> + RTA_PUT(skb, IFLA_OPERSTATE, sizeof(operstate), &operstate);
> +
> + if (event == RTM_NEWLINK)
> + RTA_PUT(skb, IFLA_PROTINFO, sizeof(portstate), &portstate);
> +
> + nlh->nlmsg_len = skb->tail - b;
> +
> + return skb->len;
> +
Is it desirable to do the above? link events already happen for each
netdevice, no? If not it would probably make more sense to export the
link netlink code (instead of replicating it as above) and just call it
for each netdevice.
I think it is worth reporting all the children (their ifindices) of a
bridge when eventing.
BTW, Where is the bridge state (as in learning, blocking etc) carried?
Having events for that i would deem as valuable.
> +static int br_rtm_setlink(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
> +{
> + struct rtattr **rta = arg;
> + struct ifinfomsg *ifm = NLMSG_DATA(nlh);
> + struct net_device *dev;
> + struct net_bridge_port *p;
> + u8 new_state;
> +
> + if (ifm->ifi_family != AF_BRIDGE)
> + return -EPFNOSUPPORT;
> +
> + /* Must pass valid state as PROTINFO */
> + if (rta[IFLA_PROTINFO-1]) {
Why not a noun like IFLA_BRIDGE_STATE ?
> + /* if kernel STP is running, don't allow changes */
> + if (p->br->stp_enabled)
> + return -EBUSY;
Hopefully above to die some day...
> +
> + p->state = new_state;
> + br_log_state(p);
Assuming the above will generate an event which reports things like the
children of the bridge and the STP state of the bridge etc i.e things in
struct net_bridge_port mostly.
cheers,
jamal
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: jamal @ 2006-05-24 18:21 UTC (permalink / raw)
To: Phil Dibowitz; +Cc: netdev, David Miller
In-Reply-To: <447412CA.50303@ipom.com>
On Wed, 2006-24-05 at 01:01 -0700, Phil Dibowitz wrote:
[..]
>
> For your reference, here's the two times I've posted it this month - I'm
> happy to send it along again.
The problem with resetting stats is it is _most definetely_ going to
break management apps like SNMP.
This is not to say this is not useful for testing and at times debugging
- but backward compat and not pissing off the standards whic count on
this long standing feature is more important. So if you can
make it work without breaking apps, it will be more palatable i am sure
to both Dave and Jeff. I would go as far as suggest that you should
allow for arbitrary setting (of which 0 is a speacial case).
cheers,
jamal
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Jeff Garzik @ 2006-05-24 18:23 UTC (permalink / raw)
To: Phil Dibowitz; +Cc: David Miller, netdev
In-Reply-To: <447412CA.50303@ipom.com>
Phil Dibowitz wrote:
> David Miller wrote:
>> Some time in the next few weeks, it is likely that the 2.6.18
>> merge window will open up shortly after a 2.6.17 release.
>>
>> So if you have major 2.6.18 submissions planned for the networking,
>> you need to start thinking about getting it to me now.
>>
>> There is a 2.6.18 tree up at:
>>
>> master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.18.git
>>
>> All it has right now is the I/O AT stuff at the moment, and I plan to
>> put Stephen Hemminger's LLC multicast/datagram changes in there as
>> well.
>
> David,
>
> I posted a patch for adding support for network device statistic
> resetting via ethtool. I saw no objections to it... it impliments the
> framework as well as skge support, so it touches both your and Jeff's area.
>
> For your reference, here's the two times I've posted it this month - I'm
> happy to send it along again.
>
> 2006-05-18
> RESEND: [PATCH] Interface Stat Clearing Framework, skge support, ethtool
> http://marc.theaimsgroup.com/?l=linux-netdev&m=114794065502155&w=2
>
> 2006-04-30
> [PATCH] Interface Stat Clearing Framework, skge support, ethtool
> http://marc.theaimsgroup.com/?l=linux-netdev&m=114636704207480&w=2
I disagree that we should bother about clearing statistics. It always
adds more complication than necessary. Few (if any) other statistics in
Linux permit easy clearing, often because adding operations other than
'increment' or 'read' requires adding expensive spinlocks or atomic
operations.
Jeff
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Rick Jones @ 2006-05-24 18:34 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Phil Dibowitz, David Miller, netdev
In-Reply-To: <4474A489.4080308@garzik.org>
Those folks wanting link-level stats over an interval (I'm assuming that
is wny someone would want to zero stats?) should feel free to embrace
and extend beforeafter:
ftp://ftp.cup.hp.com/dist/networking/tools/
rick jones
^ permalink raw reply
* Re: [patch 3/3] bridge: netlink interface for link management
From: Stephen Hemminger @ 2006-05-24 18:41 UTC (permalink / raw)
To: hadi; +Cc: netdev, David Miller
In-Reply-To: <1148494315.5325.18.camel@jzny2>
On Wed, 24 May 2006 14:11:55 -0400
jamal <hadi@cyberus.ca> wrote:
>
> Very nice.
>
> On Wed, 2006-24-05 at 10:12 -0700, Stephen Hemminger wrote:
> > plain text document attachment (bridge-netlink.patch)
> > Add basic netlink support to the Ethernet bridge. Including:
> > * dump interfaces in bridges
> > * monitor link status changes
> > * change state of bridge port
>
>
> > +static int br_fill_ifinfo(struct sk_buff *skb, const struct net_bridge_port *port,
> > + u32 pid, u32 seq, int event, unsigned int flags)
> > +{
> > + const struct net_bridge *br = port->br;
> > + const struct net_device *dev = port->dev;
> > + struct ifinfomsg *r;
> > + struct nlmsghdr *nlh;
> > + unsigned char *b = skb->tail;
> > + u32 mtu = dev->mtu;
> > + u8 operstate = netif_running(dev) ? dev->operstate : IF_OPER_DOWN;
> > + u8 portstate = port->state;
> > +
> > + pr_debug("br_fill_info event %d port %s master %s\n",
> > + event, dev->name, br->dev->name);
> > +
> > + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*r), flags);
> > + r = NLMSG_DATA(nlh);
> > + r->ifi_family = AF_BRIDGE;
> > + r->__ifi_pad = 0;
> > + r->ifi_type = dev->type;
> > + r->ifi_index = dev->ifindex;
> > + r->ifi_flags = dev_get_flags(dev);
> > + r->ifi_change = 0;
> > +
> > + RTA_PUT(skb, IFLA_IFNAME, strlen(dev->name)+1, dev->name);
> > +
> > + RTA_PUT(skb, IFLA_MASTER, sizeof(int), &br->dev->ifindex);
> > +
> > + if (dev->addr_len)
> > + RTA_PUT(skb, IFLA_ADDRESS, dev->addr_len, dev->dev_addr);
> > +
> > + RTA_PUT(skb, IFLA_MTU, sizeof(mtu), &mtu);
> > + if (dev->ifindex != dev->iflink)
> > + RTA_PUT(skb, IFLA_LINK, sizeof(int), &dev->iflink);
> > +
> > +
> > + RTA_PUT(skb, IFLA_OPERSTATE, sizeof(operstate), &operstate);
> > +
> > + if (event == RTM_NEWLINK)
> > + RTA_PUT(skb, IFLA_PROTINFO, sizeof(portstate), &portstate);
> > +
> > + nlh->nlmsg_len = skb->tail - b;
> > +
> > + return skb->len;
> > +
>
> Is it desirable to do the above? link events already happen for each
> netdevice, no? If not it would probably make more sense to export the
> link netlink code (instead of replicating it as above) and just call it
> for each netdevice.
The STP daemon only wants to know about interfaces in bridge, and it needs
to know the bridge port state.
> I think it is worth reporting all the children (their ifindices) of a
> bridge when eventing.
can easily track this in daemon.
> BTW, Where is the bridge state (as in learning, blocking etc) carried?
In IFLA_PROTINFO
> Having events for that i would deem as valuable.
>
> > +static int br_rtm_setlink(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
> > +{
> > + struct rtattr **rta = arg;
> > + struct ifinfomsg *ifm = NLMSG_DATA(nlh);
> > + struct net_device *dev;
> > + struct net_bridge_port *p;
> > + u8 new_state;
> > +
> > + if (ifm->ifi_family != AF_BRIDGE)
> > + return -EPFNOSUPPORT;
> > +
> > + /* Must pass valid state as PROTINFO */
> > + if (rta[IFLA_PROTINFO-1]) {
>
> Why not a noun like IFLA_BRIDGE_STATE ?
Laziness. Just used "protocol specific portion"
>
>
> > + /* if kernel STP is running, don't allow changes */
> > + if (p->br->stp_enabled)
> > + return -EBUSY;
>
> Hopefully above to die some day...
>
> > +
> > + p->state = new_state;
> > + br_log_state(p);
>
> Assuming the above will generate an event which reports things like the
> children of the bridge and the STP state of the bridge etc i.e things in
> struct net_bridge_port mostly.
The br_log_state just does console printk's.
^ permalink raw reply
* Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing
From: jamal @ 2006-05-24 18:43 UTC (permalink / raw)
To: Simon Oosthoek; +Cc: netdev, Stephen Hemminger
In-Reply-To: <447349A6.50105@fastmail.fm>
On Tue, 2006-23-05 at 19:43 +0200, Simon Oosthoek wrote:
> Stephen Hemminger wrote:
> > On Tue, 23 May 2006 16:07:47 +0200
> > Herman Elfrink <herman.elfrink@ti-wmc.nl> wrote:
> >
> >>
> >> FLAME stands for "Forwarding Layer for Meshing"
> >>
> >
> > Didn't you just reinvent 802.1d bridging? and/or WDS?
>
> I wouldn't say "reinvent", but the difference is small but significant.
> FLAME could be seen as ad hoc WDS, I think. It doesn't need to know
> about the other "base-stations", which I think WDS does.
>
Essentially you are extending the broadcast domain i.e a bridge within
on top of a bridge. I would question the scalability of such a beast
in the presence of many nodes. Also take a look at some of the work
Radia Perlman (who invented bridging really) is up to these days.
cheers,
jamal
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Phil Dibowitz @ 2006-05-24 18:56 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David Miller, netdev
In-Reply-To: <4474A489.4080308@garzik.org>
[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]
On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote:
> I disagree that we should bother about clearing statistics. It always
> adds more complication than necessary. Few (if any) other statistics in
> Linux permit easy clearing, often because adding operations other than
> 'increment' or 'read' requires adding expensive spinlocks or atomic
> operations.
Every networking device in the world supports clearing interface statistics.
Why should linux not be able to do the most basic operation on any
cisco/juniper/enterasys/whatever managed switch or router?
It's a common operation on a network interface, I don't see why this is a
concern.
When I'm debugging a networking issue On a cluster of hundreds and hundreds
of machines at work, I want to be able to reset them all quickly, and get a
rough idea of if they're all climbing, if they're all climbing at the same
rate, etc. And being able to do "for i in `cat hostlist`; do ssh $i ethtool -z
eth0; done" is really, really, REALLY, useful.
As for SNMP statistics, again, this is just like clearing stats on any other
platform - it's a manual thing... you're *choosing* to reset the stats, and
accept the consequences. Its not like the patch introduces some nightly
resetting - it's just an _option_ to users
It's about providing an option that requires no extra complications in the
code (at least in this case), and that has been requested on every
sysadmin-related list I'm on, and in most cases is a re-occuring topic.
--
Phil Dibowitz phil@ipom.com
Freeware and Technical Pages Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Jeff Garzik @ 2006-05-24 19:05 UTC (permalink / raw)
To: Phil Dibowitz; +Cc: David Miller, netdev
In-Reply-To: <20060524185644.GF22881@ipom.com>
Phil Dibowitz wrote:
> On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote:
>> I disagree that we should bother about clearing statistics. It always
>> adds more complication than necessary. Few (if any) other statistics in
>> Linux permit easy clearing, often because adding operations other than
>> 'increment' or 'read' requires adding expensive spinlocks or atomic
>> operations.
>
> Every networking device in the world supports clearing interface statistics.
> Why should linux not be able to do the most basic operation on any
> cisco/juniper/enterasys/whatever managed switch or router?
>
> It's a common operation on a network interface, I don't see why this is a
> concern.
>
> When I'm debugging a networking issue On a cluster of hundreds and hundreds
> of machines at work, I want to be able to reset them all quickly, and get a
> rough idea of if they're all climbing, if they're all climbing at the same
> rate, etc. And being able to do "for i in `cat hostlist`; do ssh $i ethtool -z
> eth0; done" is really, really, REALLY, useful.
Obtaining the difference between two numbers is not that difficult.
Given any method of clearing statistics across your cluster, I'm certain
you can come up with a similar method of obtaining the current statistic
(the baseline).
Jeff
^ permalink raw reply
* Re: r8169 cardbus device naming weirdness
From: Martin Hicks @ 2006-05-24 19:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: romieu, netdev
In-Reply-To: <20060523105108.7c0e2367@localhost.localdomain>
On Tue, May 23, 2006 at 10:51:08AM -0700, Stephen Hemminger wrote:
>
> Most likely some user space script is renaming it.
> Each distro seems to have it's own way of doing configuration, and most
> do something in response to the hotplug event from device registration.
> So it was eth1 until what ever ran in response to the hotplug event
> decide to change it.
of course you're right.
/me fist shakes at udev
mh
--
Martin Hicks || mort@bork.org || PGP/GnuPG: 0x4C7F2BEE
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Phil Dibowitz @ 2006-05-24 19:14 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David Miller, netdev
In-Reply-To: <4474AE92.3030501@garzik.org>
[-- Attachment #1: Type: text/plain, Size: 2406 bytes --]
On Wed, May 24, 2006 at 03:05:54PM -0400, Jeff Garzik wrote:
> Phil Dibowitz wrote:
> >On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote:
> >>I disagree that we should bother about clearing statistics. It always
> >>adds more complication than necessary. Few (if any) other statistics in
> >>Linux permit easy clearing, often because adding operations other than
> >>'increment' or 'read' requires adding expensive spinlocks or atomic
> >>operations.
> >
> >Every networking device in the world supports clearing interface
> >statistics.
> >Why should linux not be able to do the most basic operation on any
> >cisco/juniper/enterasys/whatever managed switch or router?
> >
> >It's a common operation on a network interface, I don't see why this is a
> >concern.
> >
> >When I'm debugging a networking issue On a cluster of hundreds and hundreds
> >of machines at work, I want to be able to reset them all quickly, and get a
> >rough idea of if they're all climbing, if they're all climbing at the same
> >rate, etc. And being able to do "for i in `cat hostlist`; do ssh $i
> >ethtool -z
> >eth0; done" is really, really, REALLY, useful.
>
> Obtaining the difference between two numbers is not that difficult.
>
> Given any method of clearing statistics across your cluster, I'm certain
> you can come up with a similar method of obtaining the current statistic
> (the baseline).
Right, I'm aware there are other ways of doing this - I've written scripts to
record a hundreds of numbers, and then subtract them from each other. But
those scripts are work arounds for a feature _lacking_ in the kernel. A
feature that, as I've mentioned, is supported on any piece of networking gear
(and of course, lets not forget there's a specific option in the kernel config
*just* for "behave like a router").
If my patch was invasive and broke things, I would understand the hesitation,
but this is a feature that allows people to *choose* to do this if they need
to and the code is pretty self-contained.
--
Phil Dibowitz phil@ipom.com
Freeware and Technical Pages Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Brent Cook @ 2006-05-24 20:01 UTC (permalink / raw)
To: Phil Dibowitz; +Cc: Jeff Garzik, David Miller, netdev
In-Reply-To: <20060524191442.GG22881@ipom.com>
On Wednesday 24 May 2006 14:14, Phil Dibowitz wrote:
> On Wed, May 24, 2006 at 03:05:54PM -0400, Jeff Garzik wrote:
> > Phil Dibowitz wrote:
> > Given any method of clearing statistics across your cluster, I'm certain
> > you can come up with a similar method of obtaining the current statistic
> > (the baseline).
>
> Right, I'm aware there are other ways of doing this - I've written scripts
> to record a hundreds of numbers, and then subtract them from each other.
> But those scripts are work arounds for a feature _lacking_ in the kernel. A
> feature that, as I've mentioned, is supported on any piece of networking
> gear (and of course, lets not forget there's a specific option in the
> kernel config *just* for "behave like a router").
>
> If my patch was invasive and broke things, I would understand the
> hesitation, but this is a feature that allows people to *choose* to do this
> if they need to and the code is pretty self-contained.
I'm with you - this is a useful feature! But there aren't many other things
I've found that can be cleared from the kernel other than by reloading a
module, and dmesg -c. I think the object here isn't this particular patch,
but the can-of-worms that it opens up.
Note that this is just clearing the hardware statistics on the interface, and
would not require any kind of atomic_increment addition for interfaces that
support that. It would be kind-of awkward to implement this on drivers that
increment stats in hardware though (lo, vlan, br, etc.) This also brings up
the question of resetting the stats for 'netstat -s'
What would be great is if ifconfig, netstat and their ilk just had a -z flag
instead. This would write a file to the local user's home directory with a
stats snapshot, and then every subsequent run would auto-calculate against
the snapshot. You'd also need some way of resetting this when the stats
actually _do_ reset (driver reload, reboot.) to avoid negative numbers.
That way, you can get what you want without having to write a bunch of
fragile, awkward scripts, and the kernel isn't throwing away information
either.
- Brent
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Jeff Garzik @ 2006-05-24 20:08 UTC (permalink / raw)
To: Brent Cook; +Cc: Phil Dibowitz, David Miller, netdev
In-Reply-To: <200605241501.53477.bcook@bpointsys.com>
Brent Cook wrote:
> Note that this is just clearing the hardware statistics on the interface, and
> would not require any kind of atomic_increment addition for interfaces that
> support that. It would be kind-of awkward to implement this on drivers that
> increment stats in hardware though (lo, vlan, br, etc.) This also brings up
> the question of resetting the stats for 'netstat -s'
If you don't atomically clear the statistics, then you are leaving open
a window where the stats could easily be corrupted, if the network
interface is under load.
This 'clearing' operation has implications on the rest of the statistics
usage.
More complexity, and breaking of apps, when we could just use the
existing, working system? I'll take the "do nothing, break nothing,
everything still works" route any day.
> What would be great is if ifconfig, netstat and their ilk just had a -z flag
> instead. This would write a file to the local user's home directory with a
> stats snapshot, and then every subsequent run would auto-calculate against
> the snapshot. You'd also need some way of resetting this when the stats
> actually _do_ reset (driver reload, reboot.) to avoid negative numbers.
> That way, you can get what you want without having to write a bunch of
> fragile, awkward scripts, and the kernel isn't throwing away information
> either.
See... this opens doors to tons of complexity.
Jeff
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: jamal @ 2006-05-24 20:10 UTC (permalink / raw)
To: Phil Dibowitz; +Cc: netdev, David Miller, Jeff Garzik
In-Reply-To: <20060524191442.GG22881@ipom.com>
On Wed, 2006-24-05 at 12:14 -0700, Phil Dibowitz wrote:
>
> Right, I'm aware there are other ways of doing this - I've written scripts to
> record a hundreds of numbers, and then subtract them from each other. But
> those scripts are work arounds
It is not a work around, _it is design intent_. It is what network
management tools have been expecting since the days of the caveman.
These stats are supposed to be monotonically increasing; if that
behavior is contradicted, a rollover of the counters is assumed.
> for a feature _lacking_ in the kernel. A
> feature that, as I've mentioned, is supported on any piece of networking gear
> (and of course, lets not forget there's a specific option in the kernel config
> *just* for "behave like a router").
Can you provide some link to a vendor that allows resetting ethernet
stats? I am almost certain, if they do they will have something or other
which indicates that such a reset happened. It is also easier for cisco
to have none standard feature "as of ios 15.16" which could support such
behavior because they bundle everything including network management
tools. We dont have that luxury. The BSDs may actually get away with it
because they bundle user space apps as well. Perhaps some
random Linux vendor as well..
> If my patch was invasive and broke things,
It _does break_ things for all known management apps.
This is not to say it is not useful for testing, development or
debugging (which is what you seem to be using it for) but it does mean
it is broken.
cheers,
jamal
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Rick Jones @ 2006-05-24 20:25 UTC (permalink / raw)
To: hadi; +Cc: Phil Dibowitz, netdev, David Miller, Jeff Garzik
In-Reply-To: <1148501433.5325.52.camel@jzny2>
> Can you provide some link to a vendor that allows resetting ethernet
> stats? I am almost certain, if they do they will have something or other
> which indicates that such a reset happened. It is also easier for cisco
> to have none standard feature "as of ios 15.16" which could support such
> behavior because they bundle everything including network management
> tools. We dont have that luxury. The BSDs may actually get away with it
> because they bundle user space apps as well. Perhaps some
> random Linux vendor as well..
The lanadmin (think ethtool) command of HP-UX has had a way to clear the
statistics reported by lanadmin. I do not know however, if that affects
the stats in the actual SNMP interface MIBs as I've never had occasion
to look.
I still suggest beforeafter to people because clearing the lanadmin
stats requires root privs and because it may not be a kosher thing to do
on a customer system.
HP-UX does not provide a way to clear the stats reported by netstat.
fwiw,
rick jones
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Brian Haley @ 2006-05-24 20:44 UTC (permalink / raw)
To: hadi; +Cc: Phil Dibowitz, netdev, David Miller, Jeff Garzik
In-Reply-To: <1148501433.5325.52.camel@jzny2>
jamal wrote:
> On Wed, 2006-24-05 at 12:14 -0700, Phil Dibowitz wrote:
>
>>Right, I'm aware there are other ways of doing this - I've written scripts to
>>record a hundreds of numbers, and then subtract them from each other. But
>>those scripts are work arounds
I don't have any problem with Phil's changes.
> It is not a work around, _it is design intent_. It is what network
> management tools have been expecting since the days of the caveman.
> These stats are supposed to be monotonically increasing; if that
> behavior is contradicted, a rollover of the counters is assumed.
So how is this different than if an SNMP station probes my system, then
I reboot, then they probe again. Things will seem to have gone
backwards, but they deal with that just fine.
>>for a feature _lacking_ in the kernel. A
>>feature that, as I've mentioned, is supported on any piece of networking gear
>>(and of course, lets not forget there's a specific option in the kernel config
>>*just* for "behave like a router").
>
>
> Can you provide some link to a vendor that allows resetting ethernet
> stats? I am almost certain, if they do they will have something or other
> which indicates that such a reset happened.
DEC/Compaq/HP has allowed this on Tru64 UNIX since 1999 because we had
customers that wanted it, noone ever complained about complications with
SNMP. We did save the last time the stats were zero'd in the struct for
posterity, but that was never get-able via SNMP:
--> netstat -I tu0 -s
tu0 Ethernet counters at Wed May 24 16:30:05 2006
609415 seconds since last zeroed
3943458720 bytes received
113576310 bytes sent
...
Maybe saving a "ztime" would make people happier?
> It is also easier for cisco
> to have none standard feature "as of ios 15.16" which could support such
> behavior because they bundle everything including network management
> tools.
I never received any free management tools with my Cisco routers :) ,
they charge big bucks for that stuff!
>>If my patch was invasive and broke things,
>
> It _does break_ things for all known management apps.
Can anyone show a management app this breaks?
-Brian
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Phil Dibowitz @ 2006-05-24 20:48 UTC (permalink / raw)
To: jamal; +Cc: netdev, David Miller, Jeff Garzik
In-Reply-To: <1148501433.5325.52.camel@jzny2>
[-- Attachment #1: Type: text/plain, Size: 4498 bytes --]
On Wed, May 24, 2006 at 04:10:32PM -0400, jamal wrote:
> Can you provide some link to a vendor that allows resetting ethernet
> stats? I am almost certain, if they do they will have something or other
> which indicates that such a reset happened. It is also easier for cisco
> to have none standard feature "as of ios 15.16" which could support such
> behavior because they bundle everything including network management
> tools. We dont have that luxury. The BSDs may actually get away with it
> because they bundle user space apps as well. Perhaps some
> random Linux vendor as well..
Well, I can show you support on my home switch (cabletron) - the network guys
will be a little unhappy if I clear stats on our production network (cisco)
without warning them:
*****************************************************************************
Cabletron Systems ELS100-24TXG
SWITCH STATISTICS Access Control: READ/WRITE
ID TRANSMITTED RECEIVED FORWARDED FILTERED DROPPED ERRORED
-----------------------------------------------------------------------------
1 1322815 1614038 1614038 0 0 51562
2 2067032 18142545 18142349 0 196 0
3 17487573 1011964 1011964 0 0 0
4 18247 20528 20528 0 0 0
5 38775 0 0 0 0 0
6 38775 0 0 0 0 0
7 38775 0 0 0 0 0
8 38775 0 0 0 0 0
9 38820 0 0 0 0 0
10 38820 0 0 0 0 0
n. Next Page p. Previous Page f. First Page l. Last Page
s. Switch Summary d. Port Statistics t. Trunking Statistics
r. Refresh c. Clear x. Previous Menu
Enter Selection:c
*****************************************************************************
Cabletron Systems ELS100-24TXG
SWITCH STATISTICS Access Control: READ/WRITE
ID TRANSMITTED RECEIVED FORWARDED FILTERED DROPPED ERRORED
-----------------------------------------------------------------------------
1 0 0 0 0 0 0
2 0 0 0 0 0 0
3 0 0 0 0 0 0
4 0 0 0 0 0 0
5 0 0 0 0 0 0
6 0 0 0 0 0 0
7 0 0 0 0 0 0
8 0 0 0 0 0 0
9 0 0 0 0 0 0
10 0 0 0 0 0 0
n. Next Page p. Previous Page f. First Page l. Last Page
s. Switch Summary d. Port Statistics t. Trunking Statistics
r. Refresh c. Clear x. Previous Menu
Enter Selection:
> > If my patch was invasive and broke things,
>
> It _does break_ things for all known management apps.
> This is not to say it is not useful for testing, development or
> debugging (which is what you seem to be using it for) but it does mean
> it is broken.
Does having the ability to boot into single user mode break networking? No, it
*allows* you to break networking. Does the _support_ of rmmod break the
kernel? No, but it *allows* you to.
Same thing here. The patch breaks nothing, it provides a tool that if used
without proper understanding, could break things. Just like almost any other
feature in the kernel.
--
Phil Dibowitz phil@ipom.com
Freeware and Technical Pages Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing
From: Pavel Machek @ 2006-05-24 20:50 UTC (permalink / raw)
To: Herman Elfrink; +Cc: netdev, linux-kernel
In-Reply-To: <44731733.7000204@ti-wmc.nl>
Hi!
> FLAME stands for "Forwarding Layer for Meshing"
>
> FLAME provides an intermediate layer between the network
> layer (e.g. IPv4/IPv6) and the link (MAC) layer,
> providing L2.5 meshing. Both network layer and MAC layer
What is wrong with meshing on L3?
(It is called flame so lets at least have nice flamewar :-)
Pavel
--
Thanks for all the (sleeping) penguins.
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Andy @ 2006-05-24 20:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Phil Dibowitz, David Miller, netdev
In-Reply-To: <4474A489.4080308@garzik.org>
On Wed, 2006-05-24 at 14:23 -0400, Jeff Garzik wrote:
> I disagree that we should bother about clearing statistics. It always
> adds more complication than necessary. Few (if any) other statistics in
> Linux permit easy clearing,
iptables -Z
> often because adding operations other than
> 'increment' or 'read' requires adding expensive spinlocks or atomic
> operations.
Why is 'set to N' so different from 'increment'?
- Andy
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Rick Jones @ 2006-05-24 21:01 UTC (permalink / raw)
To: Brian Haley; +Cc: hadi, Phil Dibowitz, netdev, David Miller, Jeff Garzik
In-Reply-To: <4474C5A7.2070703@hp.com>
> So how is this different than if an SNMP station probes my system, then
> I reboot, then they probe again. Things will seem to have gone
> backwards, but they deal with that just fine.
In that case hasn't the system's uptime and/or last boot time in the MIB
changed and so indicates to the management station that it has been
rebooted? It is also possible that the shutdown procedures or the
rebooting procedures would have generated an SNMP trap to the management
station(s) informing them of the reboot.
rick jones
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Rick Jones @ 2006-05-24 21:04 UTC (permalink / raw)
To: Phil Dibowitz; +Cc: jamal, netdev, David Miller, Jeff Garzik
In-Reply-To: <20060524204800.GH22881@ipom.com>
Phil Dibowitz wrote:
> Well, I can show you support on my home switch (cabletron) - the network guys
> will be a little unhappy if I clear stats on our production network (cisco)
> without warning them:
Isn't that last bit an example of why it might not be good to play-out
that rope?-)
> Does having the ability to boot into single user mode break networking? No, it
> *allows* you to break networking. Does the _support_ of rmmod break the
> kernel? No, but it *allows* you to.
Are SNMP traps generated by going into single-user mode? Rather like
what I was saying to Brian earlier. I suspect though that an rmmod
doesn't generate an SNMP trap - unless perhaps that to do the rmmod one
has to first ifdown the interface and that might?
rick jones
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Ben Greear @ 2006-05-24 21:10 UTC (permalink / raw)
To: Rick Jones; +Cc: Phil Dibowitz, jamal, netdev, David Miller, Jeff Garzik
In-Reply-To: <4474CA66.5020401@hp.com>
Rick Jones wrote:
> Phil Dibowitz wrote:
>> Does having the ability to boot into single user mode break
>> networking? No, it
>> *allows* you to break networking. Does the _support_ of rmmod break the
>> kernel? No, but it *allows* you to.
>
>
> Are SNMP traps generated by going into single-user mode? Rather like
> what I was saying to Brian earlier. I suspect though that an rmmod
> doesn't generate an SNMP trap - unless perhaps that to do the rmmod one
> has to first ifdown the interface and that might?
If the interface comes back, it will (may?) have a different device id (if-index),
even if the name is the same.
Regardless, not everyone uses SNMP, so clearing stats can still be useful. Even
if it is not implemented perfectly (ie, no locking, so it's possible that a clear
will not totally clear some stats), it will still be right most of the time, and
that will help the casual user who is trying to diagnose network errors with only
console access to the system... (ie, ifconfig -a).
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 3/4] myri10ge - Driver core
From: Anton Blanchard @ 2006-05-24 21:21 UTC (permalink / raw)
To: Brice Goglin; +Cc: netdev, gallatin, linux-kernel, benh
In-Reply-To: <4474138C.2050705@myri.com>
Hi,
> We didn't get any ppc64 with PCI-E to run Linux so far. What performance
> drop should we expect with our current code ?
We have seen > 20% improvement on ppc64 running some networking
workloads when forcing 128 byte alignment (instead of 16 byte
alignment). DMA writes have to get cacheline aligned (in power of 2
steps) on some IO chips.
> I am not sure what you mean.
> The only ppc64 with PCI-E that we have seen so far (a G5) couldn't do
> write combining according to Apple.
Im thinking more generally, MTRRs are x86 specific and it would be good
to have a more generic way to enable write combining.
Anton
^ permalink raw reply
* Re: [patch 1/2] spidernet: enable support for bcm5461 ethernet phy
From: Jens Osterkamp @ 2006-05-24 21:23 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Arnd Bergmann, netdev, Utz Bacher
In-Reply-To: <4473EF34.7050007@pobox.com>
Jeff Garzik <jgarzik@pobox.com> wrote on 05/24/2006 07:29:24 AM:
> NAK, failed to apply. Also, the whitespace above is borked.
I think the patch is already in 2.6.17-rc4. I will send send a patch to
turn the whitespaces into
tabs.
Jens
^ permalink raw reply
* spidernet: replace whitespaces by tabs
From: Jens Osterkamp @ 2006-05-24 21:33 UTC (permalink / raw)
To: jgarzik; +Cc: arnd, utz.bacher, maxim, netdev, cbe-oss-dev
From: Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
The original patch was using whitespaces instead of tabs.
Signed-off-by: Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Index: linux-2.6.17-rc4/drivers/net/sungem_phy.c
===================================================================
--- linux-2.6.17-rc4.orig/drivers/net/sungem_phy.c
+++ linux-2.6.17-rc4/drivers/net/sungem_phy.c
@@ -345,9 +345,9 @@ static int bcm5421_enable_fiber(struct m
static int bcm5461_enable_fiber(struct mii_phy* phy)
{
- phy_write(phy, MII_NCONFIG, 0xfc0c);
- phy_write(phy, MII_BMCR, 0x4140);
- phy_write(phy, MII_NCONFIG, 0xfc0b);
+ phy_write(phy, MII_NCONFIG, 0xfc0c);
+ phy_write(phy, MII_BMCR, 0x4140);
+ phy_write(phy, MII_NCONFIG, 0xfc0b);
phy_write(phy, MII_BMCR, 0x0140);
return 0;
^ permalink raw reply
* [PATCH 1/4] b44: add wol and setup for later 4401
From: Gary Zambrano @ 2006-05-24 14:40 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
This patch adds set and get functions and support for the later 4401 revs.
Signed-off-by: Gary Zambrano <zambrano@broadcom.com>
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 7b3dfc4..e42e0aa 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -75,6 +75,12 @@
/* minimum number of free TX descriptors required to wake up TX process */
#define B44_TX_WAKEUP_THRESH (B44_TX_RING_SIZE / 4)
+/* b44 internal pattern match filter info */
+#define B44_WOL_PATTERN_BASE 0x400
+#define B44_WOL_PATTERN_SIZE 0x80
+#define B44_WOL_MASK_BASE 0x600
+#define B44_WOL_MASK_SIZE 0x10
+
static char version[] __devinitdata =
DRV_MODULE_NAME ".c:v" DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
@@ -1442,6 +1448,43 @@ static void b44_poll_controller(struct n
}
#endif
+
+static void b44_setup_wol(struct b44 *bp)
+{
+ u32 val;
+ u16 pmval;
+
+ bw32(bp, B44_RXCONFIG, RXCONFIG_ALLMULTI);
+
+ if (bp->flags & B44_FLAG_B0_ANDLATER) {
+
+ bw32 (bp, B44_WKUP_LEN, WKUP_LEN_DISABLE);
+
+ val = bp->dev->dev_addr[2] << 24 |
+ bp->dev->dev_addr[3] << 16 |
+ bp->dev->dev_addr[4] << 8 |
+ bp->dev->dev_addr[5];
+ bw32(bp, B44_ADDR_LO, val);
+
+ val = bp->dev->dev_addr[0] << 8 |
+ bp->dev->dev_addr[1];
+ bw32(bp, B44_ADDR_HI, val);
+
+ val = br32(bp, B44_DEVCTRL);
+ bw32(bp, B44_DEVCTRL, val | DEVCTRL_MPM | DEVCTRL_PFE);
+
+ } else {
+ b44_setup_pseudo_magicp(bp);
+ }
+
+ val = br32(bp, B44_SBTMSLOW);
+ bw32(bp, B44_SBTMSLOW, val | SBTMSLOW_PE);
+
+ pci_read_config_word(bp->pdev, SSB_PMCSR, &pmval);
+ pci_write_config_word(bp->pdev, SSB_PMCSR, pmval | SSB_PE);
+
+}
+
static int b44_close(struct net_device *dev)
{
struct b44 *bp = netdev_priv(dev);
@@ -1467,6 +1510,11 @@ static int b44_close(struct net_device *
netif_poll_enable(dev);
+ if (bp->flags & B44_FLAG_WOL_ENABLE){
+ b44_init_hw(bp);
+ b44_setup_wol(bp);
+ }
+
b44_free_consistent(bp);
return 0;
@@ -1810,12 +1858,38 @@ static void b44_get_ethtool_stats(struct
spin_unlock_irq(&bp->lock);
}
+static void b44_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ struct b44 *bp = netdev_priv(dev);
+
+ wol->supported = WAKE_MAGIC;
+ if (bp->flags & B44_FLAG_WOL_ENABLE)
+ wol->wolopts = WAKE_MAGIC;
+ else
+ wol->wolopts = 0;
+ memset(&wol->sopass, 0, sizeof(wol->sopass));
+}
+
+static int b44_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ struct b44 *bp = netdev_priv(dev);
+
+ if (wol->wolopts & WAKE_MAGIC)
+ bp->flags |= B44_FLAG_WOL_ENABLE;
+ else
+ bp->flags &= ~B44_FLAG_WOL_ENABLE;
+
+ return 0;
+}
+
static struct ethtool_ops b44_ethtool_ops = {
.get_drvinfo = b44_get_drvinfo,
.get_settings = b44_get_settings,
.set_settings = b44_set_settings,
.nway_reset = b44_nway_reset,
.get_link = ethtool_op_get_link,
+ .get_wol = b44_get_wol,
+ .set_wol = b44_set_wol,
.get_ringparam = b44_get_ringparam,
.set_ringparam = b44_set_ringparam,
.get_pauseparam = b44_get_pauseparam,
@@ -1894,6 +1968,10 @@ static int __devinit b44_get_invariants(
/* XXX - really required?
bp->flags |= B44_FLAG_BUGGY_TXPTR;
*/
+
+ if (ssb_get_core_rev(bp) >= 7)
+ bp->flags |= B44_FLAG_B0_ANDLATER;
+
out:
return err;
}
diff --git a/drivers/net/b44.h b/drivers/net/b44.h
index b178662..18baa19 100644
--- a/drivers/net/b44.h
+++ b/drivers/net/b44.h
@@ -24,6 +24,8 @@
#define WKUP_LEN_P3_MASK 0x7f000000 /* Pattern 3 */
#define WKUP_LEN_P3_SHIFT 24
#define WKUP_LEN_D3 0x80000000
+#define WKUP_LEN_DISABLE 0x80808080
+#define WKUP_LEN_ENABLE_TWO 0x80800000
#define B44_ISTAT 0x0020UL /* Interrupt Status */
#define ISTAT_LS 0x00000020 /* Link Change (B0 only) */
#define ISTAT_PME 0x00000040 /* Power Management Event */
@@ -264,6 +266,8 @@
#define SBIDHIGH_VC_SHIFT 16
/* SSB PCI config space registers. */
+#define SSB_PMCSR 0x44
+#define SSB_PE 0x100
#define SSB_BAR0_WIN 0x80
#define SSB_BAR1_WIN 0x84
#define SSB_SPROM_CONTROL 0x88
@@ -420,6 +424,7 @@ struct b44 {
u32 dma_offset;
u32 flags;
+#define B44_FLAG_B0_ANDLATER 0x00000001
#define B44_FLAG_BUGGY_TXPTR 0x00000002
#define B44_FLAG_REORDER_BUG 0x00000004
#define B44_FLAG_PAUSE_AUTO 0x00008000
@@ -435,6 +440,7 @@ struct b44 {
#define B44_FLAG_INTERNAL_PHY 0x10000000
#define B44_FLAG_RX_RING_HACK 0x20000000
#define B44_FLAG_TX_RING_HACK 0x40000000
+#define B44_FLAG_WOL_ENABLE 0x80000000
u32 rx_offset;
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox