Network activity LED trigger

Network activity LED trigger

[Florian Fainelli]

Hi All,

I have been talking a bit with Richard, who is the LED API maintainer, and a 
LED trigger based on network activity would be something great.

There are somethings that concern the network stack :

- should we specify if the network driver is allowed to contribute to
the LED activity, just like it is done for random generation, at compile time

- I would like to trigger the LED based on one or several network
interfaces, maybe specify via sysfs which interface triggers which LED,
and also maybe differentiate the layer-2 activity from the layer-3
activity for instance

- A led driver could by default be bound to a network driver, or an interface 
name

As it could be very intrusive in the network stack, you might want to specify 
a bit more how you imagine a network activity trigger.

Thanks
-- 

Re: Network activity LED trigger

[Florian Fainelli]

Hi All,

Some more thoughts. The IDE activity LED trigger is currently triggered when a 
function is called in the IDE writing/reading routines.

In a similar way, we could call the trigger function in net/core/dev.c in 
netif_receive_skb and netif_rx ?

I was also thinking that some network NIC already have LEDs, so it is not 
necessary for those models to "overload" the user with lights everywhere.

Regars, Florian

Le jeudi 1 mars 2007, Florian Fainelli a écrit :
> Hi All,
>
> I have been talking a bit with Richard, who is the LED API maintainer, and
> a LED trigger based on network activity would be something great.
>
> There are somethings that concern the network stack :
>
> - should we specify if the network driver is allowed to contribute to
> the LED activity, just like it is done for random generation, at compile
> time
>
> - I would like to trigger the LED based on one or several network
> interfaces, maybe specify via sysfs which interface triggers which LED,
> and also maybe differentiate the layer-2 activity from the layer-3
> activity for instance
>
> - A led driver could by default be bound to a network driver, or an
> interface name
>
> As it could be very intrusive in the network stack, you might want to
> specify a bit more how you imagine a network activity trigger.
>
> Thanks

Re: Network activity LED trigger

[jamal]

Where are these LEDs typically located? Are you talking about LEDs on a
network card for example? can you light them up in different colors?

cheers,
jamal

On Fri, 2007-02-03 at 13:58 +0100, Florian Fainelli wrote:
> Hi All,
> 
> Some more thoughts. The IDE activity LED trigger is currently triggered when a 
> function is called in the IDE writing/reading routines.
> 
> In a similar way, we could call the trigger function in net/core/dev.c in 
> netif_receive_skb and netif_rx ?
> 
> I was also thinking that some network NIC already have LEDs, so it is not 
> necessary for those models to "overload" the user with lights everywhere.
> 
> R

Re: Network activity LED trigger

[Florian Fainelli]

Hi,

Le vendredi 2 mars 2007, jamal a écrit :
> Where are these LEDs typically located? Are you talking about LEDs on a
> network card for example? can you light them up in different colors?

Those LEDS are typically controlled by GPIO lines visible in front of the 
device. It is mostly targeted to embedded devices for which you do not 
necessarily want to assign a LED to a given network interface

>
> cheers,
> jamal
>
> On Fri, 2007-02-03 at 13:58 +0100, Florian Fainelli wrote:
> > Hi All,
> >
> > Some more thoughts. The IDE activity LED trigger is currently triggered
> > when a function is called in the IDE writing/reading routines.
> >
> > In a similar way, we could call the trigger function in net/core/dev.c in
> > netif_receive_skb and netif_rx ?
> >
> > I was also thinking that some network NIC already have LEDs, so it is not
> > necessary for those models to "overload" the user with lights everywhere.
> >
> > R
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Cordialement, Florian Fainelli
---------------------------------------------
5, rue Charles Fourier
Chambre 1202
91011 Evry
http://www.alphacore.net
(+33) 01 60 76 64 21
(+33) 06 09 02 64 95
---------------------------------------------
Association MiNET
http://www.minet.net
---------------------------------------------
Institut National des Télécommunication
http://www.int-evry.fr/telecomint
---------------------------------------------

Re: Network activity LED trigger

[jamal]

On Fri, 2007-02-03 at 15:16 +0100, Florian Fainelli wrote:
> Hi,
> 
> Le vendredi 2 mars 2007, jamal a écrit :
> > Where are these LEDs typically located? Are you talking about LEDs on a
> > network card for example? can you light them up in different colors?
> 
> Those LEDS are typically controlled by GPIO lines visible in front of the 
> device. It is mostly targeted to embedded devices for which you do not 
> necessarily want to assign a LED to a given network interface
> 

Ah, ok - ive worked with a not-so-embedded board that had something that
was accessible via the ICH; i recall writting a user-space program to
handle it. So instead of calling this just LED, probably find a more
descriptive name for it; Example GPIO-LED.

Those things are tricky to have in a generic code though, no? I.e each
chipset/board will have different address mappings on where to
read/write for a specific LED. So you need to deal with that problem
without requiring changing of the kernel every time an address changes.
I actually found exactly similar board (some manufacturer) but the
firmware was slightly different.

Heres my view of what would be useful:
Have them accessible via the kernel, but also have an API from user
space. This way user space apps can control the LED, but if i wanted to
do it from the kernel i could as well. In my case i was actually
monitoring the health of a daemon; it would show off if the daemon was
not running, green if it was happy, yellow if semi-healthy and Red if it
was in trouble.

here are some operations/messages i can see that are useful which you
probably already have in your API:

turn on LED at #x color somecolor
turn off LED at #y
query LED info at #x
dump all LEDs on board - think of this as a discovery
flicker LED at #z at frequency y color green
maybe even: "I am a wireless card with no LED, I claim LED #x"
which is matched by "tell me if anyone owns LED code"

In other words, if you just provide mechanims let people write the
policies.
This way if i wanted to tie it to my eth0 i can. 

Hope that helps.

cheers,
jamal

Re: Network activity LED trigger

[Richard Purdie]

On Fri, 2007-03-02 at 10:16 -0500, jamal wrote:
> Heres my view of what would be useful:
> Have them accessible via the kernel, but also have an API from user
> space. This way user space apps can control the LED, but if i wanted to
> do it from the kernel i could as well. In my case i was actually
> monitoring the health of a daemon; it would show off if the daemon was
> not running, green if it was happy, yellow if semi-healthy and Red if it
> was in trouble.

We already have this API, see drivers/leds ;-)

> here are some operations/messages i can see that are useful which you
> probably already have in your API:
> 
> turn on LED at #x color somecolor
> turn off LED at #y
> query LED info at #x
> dump all LEDs on board - think of this as a discovery
> flicker LED at #z at frequency y color green
> maybe even: "I am a wireless card with no LED, I claim LED #x"
> which is matched by "tell me if anyone owns LED code"
> 
> In other words, if you just provide mechanims let people write the
> policies.
> This way if i wanted to tie it to my eth0 i can. 

We have LEDs which show up in sysfs and can be controlled by userspace
from there. They can also choose to be controlled by kernel LED
'triggers', for example. we have an IDE disk trigger which shows up
activity on IDE disks. Florian would like to see a network trigger.

The LED trigger code is quite generic and designed to have little impact
on the subsystem its added to, at least in terms of code. As always,
there will be some runtime overhead though. Ultimately it depends how
complex you make the trigger (eg. how many options it has) and where and
how you hook it into the network subsystem. I know little about the
network subsystem so this is something others will have to advise on.

Cheers,

Richard 
(LED Maintainer)

Re: Network activity LED trigger

[jamal]

On Fri, 2007-02-03 at 16:03 +0000, Richard Purdie wrote:
> On Fri, 2007-03-02 at 10:16 -0500, jamal wrote:

> We already have this API, see drivers/leds ;-)

Very cool ;-> I was not aware of the existence of this API.
Actually i dont think it was available around 2.6.10.

> We have LEDs which show up in sysfs and can be controlled by userspace
> from there. They can also choose to be controlled by kernel LED
> 'triggers', for example. we have an IDE disk trigger which shows up
> activity on IDE disks. Florian would like to see a network trigger.
> 

This literally covers most of what i wanted; it may be too late to get
rid of that user space program but it is something i see you already
support;->

> The LED trigger code is quite generic and designed to have little impact
> on the subsystem its added to, at least in terms of code. As always,
> there will be some runtime overhead though. Ultimately it depends how
> complex you make the trigger (eg. how many options it has) and where 


Well, give me pointers and i will send you a patch for a board i
currently use:
http://download.intel.com/design/telecom/techspec/9635.pdf
which has GPIO LED.
I take it i would have to write a "driver" using your API?

> and how you hook it into the network subsystem. 
> I know little about the
> network subsystem so this is something others will have to advise on.

Other people may have different opionions: I cant think of something
useful from a network perspective mostly because you cant make it
generic enough i.e some boards will have LEDs for their NICs and some
wont. Just as some boards have activity LEDS for their IDE disks. IOW, I
think general purpose LEDs will probably be very dependent on the
shipping product.

other than that, great work!

cheers,
jamal

Re: Network activity LED trigger

[Florian Fainelli]

[-- Attachment #1.1: Type: text/plain, Size: 477 bytes --]

Hi all,

Here comes a basic patch that adds a network led activity. It is not 
configurable yet, but is enough to make a LED configured with 
the "network-activity" trigger to blink on network activity.

Netdev people can probably comment on the place of ledtrig_network_activity(), 
which is probably not adequate. Also the ledtrig_network_activity can be 
network device specific for instance.

Signed-off-by: Florian Fainelli <florian.fainelli@telecomint.eu>
--

[-- Attachment #1.2: ledtrig_network.patch --]
[-- Type: text/plain, Size: 4024 bytes --]

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 80acd08..25d2b58 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -127,5 +127,12 @@ config LEDS_TRIGGER_HEARTBEAT
 	  load average.
 	  If unsure, say Y.
 
+config LEDS_TRIGGER_NETWORK_ACT
+	tristate "LED Network Activity Trigger"
+	depends on LEDS_TRIGGER && NET
+	help
+	  This allow LEDs to be controlled by network activity at layer-3 networking.
+	  If unsure, say Y.
+
 endmenu
 
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index aa2c18e..bc899d3 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_LEDS_COBALT)		+= leds-cobalt.o
 obj-$(CONFIG_LEDS_TRIGGER_TIMER)	+= ledtrig-timer.o
 obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)	+= ledtrig-ide-disk.o
 obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT)	+= ledtrig-heartbeat.o
+obj-$(CONFIG_LEDS_TRIGGER_NETWORK_ACT)  += ledtrig-network-activity.o
diff --git a/drivers/leds/ledtrig-network-activity.c b/drivers/leds/ledtrig-network-activity.c
new file mode 100644
index 0000000..88d17bb
--- /dev/null
+++ b/drivers/leds/ledtrig-network-activity.c
@@ -0,0 +1,61 @@
+/*
+ * LED Network Activity Trigger
+ * based on ledtrig-ide-disk by Richard Purdie
+ * 
+ * Copyright 2007 Florian Fainelli <florian@openwrt.org>
+ * 
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * 
+ */
+
+#include <linux/module.h>
+#include <linux/jiffies.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/timer.h>
+#include <linux/leds.h>
+
+static void ledtrig_network_timerfunc(unsigned long data);
+
+DEFINE_LED_TRIGGER(ledtrig_network);
+static DEFINE_TIMER(ledtrig_network_timer, ledtrig_network_timerfunc, 0, 0);
+static int network_activity, network_lastactivity;
+
+void ledtrig_network_activity(void)
+{
+	network_activity++;
+	if (!timer_pending(&ledtrig_network_timer))
+		mod_timer(&ledtrig_network_timer, jiffies + msecs_to_jiffies(10));
+}
+EXPORT_SYMBOL(ledtrig_network_activity);
+
+static void ledtrig_network_timerfunc(unsigned long data)
+{
+	if (network_lastactivity != network_activity) {
+		network_lastactivity = network_activity;
+		led_trigger_event(ledtrig_network, LED_FULL);
+		mod_timer(&ledtrig_network_timer, jiffies + msecs_to_jiffies(10));
+	} else {
+		led_trigger_event(ledtrig_network, LED_OFF);
+	}
+}
+
+static int __init ledtrig_network_init(void)
+{
+	led_trigger_register_simple("network-activity", &ledtrig_network);
+	return 0;
+}
+
+static void __exit ledtrig_network_exit(void)
+{
+	led_trigger_unregister_simple(ledtrig_network);
+}
+
+module_init(ledtrig_network_init);
+module_exit(ledtrig_network_exit);
+
+MODULE_AUTHOR("Florian Fainelli <florian@openwrt.org>");
+MODULE_DESCRIPTION("LED Network Activity trigger");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 88afcef..ed3774e 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -110,4 +110,10 @@ extern void ledtrig_ide_activity(void);
 #define ledtrig_ide_activity() do {} while(0)
 #endif
 
+#ifdef CONFIG_LEDS_TRIGGER_NETWORK_ACT
+extern void ledtrig_network_activity(void);
+#else
+#define ledtrig_network_activity() do {} while(0)
+#endif
+
 #endif		/* __LINUX_LEDS_H_INCLUDED */
diff --git a/net/core/dev.c b/net/core/dev.c
index 4317c1b..9423b26 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -116,6 +116,7 @@
 #include <linux/dmaengine.h>
 #include <linux/err.h>
 #include <linux/ctype.h>
+#include <linux/leds.h>
 
 /*
  *	The list of packet types we will receive (as opposed to discard)
@@ -1451,6 +1452,8 @@ int dev_queue_xmit(struct sk_buff *skb)
 gso:
 	spin_lock_prefetch(&dev->queue_lock);
 
+	ledtrig_network_activity();
+
 	/* Disable soft irqs for various locks below. Also
 	 * stops preemption for RCU.
 	 */

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Network activity LED trigger

[jamal]

On Thu, 2007-10-05 at 21:21 +0200, Florian Fainelli wrote:

> Netdev people can probably comment on the place of ledtrig_network_activity(), 
> which is probably not adequate. Also the ledtrig_network_activity can be 
> network device specific for instance.

Thanks for CCing me Florian.
Yes, ledtrig_network_activity() should be device specific - given the
spot you have it at. Just pass dev->name for example and filter on
whether the user wanted that specific device.

Additionaly is there a way to sort of light different colors depending
whether it is an incoming packet or outgoing?
Then you can pass a hook number OUT in the case where you have
ledtrig_network_activity() at the moment. This way we can add
multiple hooks within the network stack.
I dont remember the original patches you posted, but could you have 
multiple LEDs as well?

cheers,
jamal

Re: Network activity LED trigger

[Andi Kleen]

Florian Fainelli <florian.fainelli@int-evry.fr> writes:

> Hi All,
> 
> I have been talking a bit with Richard, who is the LED API maintainer, and a 
> LED trigger based on network activity would be something great.

You should be aware that normally the kernel doesn't see all packets
on a ethernet unless promiscuous mode is enabled (which it is normally 
not). That is because the hardware filters out all packets
not for this host. A software controlled LED wouldn't be equivalent
to the activity LEDs you normally have on network cards,
but only show local traffic.

That said if you want to get events for any in/outgoing packets
you can use the same hooks as PF_PACKET uses for sniffing;
using dev_add_pack with ETH_P_ALL.
That will get you all incoming and outgoing packets that 
are local.

And when someone runs tcpdump it will suddenly see all which
might be unexpected.

-Andi

Network activity LED trigger

[Florian Fainelli]

[-- Attachment #1.1: Type: text/plain, Size: 465 bytes --]

Here comes a basic patch that adds a network led activity. It is not 
configurable yet, but is enough to make a LED configured with 
the "network-activity" trigger to blink on network activity.

Netdev people can probably comment on the place of ledtrig_network_activity(), 
which is probably not adequate. Also the ledtrig_network_activity can be 
network device specific for instance.

Signed-off-by: Florian Fainelli <florian.fainelli@int-evry.fr>
-- 

[-- Attachment #1.2: ledtrig_network.patch --]
[-- Type: text/plain, Size: 4024 bytes --]

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 80acd08..25d2b58 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -127,5 +127,12 @@ config LEDS_TRIGGER_HEARTBEAT
 	  load average.
 	  If unsure, say Y.
 
+config LEDS_TRIGGER_NETWORK_ACT
+	tristate "LED Network Activity Trigger"
+	depends on LEDS_TRIGGER && NET
+	help
+	  This allow LEDs to be controlled by network activity at layer-3 networking.
+	  If unsure, say Y.
+
 endmenu
 
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index aa2c18e..bc899d3 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_LEDS_COBALT)		+= leds-cobalt.o
 obj-$(CONFIG_LEDS_TRIGGER_TIMER)	+= ledtrig-timer.o
 obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)	+= ledtrig-ide-disk.o
 obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT)	+= ledtrig-heartbeat.o
+obj-$(CONFIG_LEDS_TRIGGER_NETWORK_ACT)  += ledtrig-network-activity.o
diff --git a/drivers/leds/ledtrig-network-activity.c b/drivers/leds/ledtrig-network-activity.c
new file mode 100644
index 0000000..88d17bb
--- /dev/null
+++ b/drivers/leds/ledtrig-network-activity.c
@@ -0,0 +1,61 @@
+/*
+ * LED Network Activity Trigger
+ * based on ledtrig-ide-disk by Richard Purdie
+ * 
+ * Copyright 2007 Florian Fainelli <florian@openwrt.org>
+ * 
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * 
+ */
+
+#include <linux/module.h>
+#include <linux/jiffies.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/timer.h>
+#include <linux/leds.h>
+
+static void ledtrig_network_timerfunc(unsigned long data);
+
+DEFINE_LED_TRIGGER(ledtrig_network);
+static DEFINE_TIMER(ledtrig_network_timer, ledtrig_network_timerfunc, 0, 0);
+static int network_activity, network_lastactivity;
+
+void ledtrig_network_activity(void)
+{
+	network_activity++;
+	if (!timer_pending(&ledtrig_network_timer))
+		mod_timer(&ledtrig_network_timer, jiffies + msecs_to_jiffies(10));
+}
+EXPORT_SYMBOL(ledtrig_network_activity);
+
+static void ledtrig_network_timerfunc(unsigned long data)
+{
+	if (network_lastactivity != network_activity) {
+		network_lastactivity = network_activity;
+		led_trigger_event(ledtrig_network, LED_FULL);
+		mod_timer(&ledtrig_network_timer, jiffies + msecs_to_jiffies(10));
+	} else {
+		led_trigger_event(ledtrig_network, LED_OFF);
+	}
+}
+
+static int __init ledtrig_network_init(void)
+{
+	led_trigger_register_simple("network-activity", &ledtrig_network);
+	return 0;
+}
+
+static void __exit ledtrig_network_exit(void)
+{
+	led_trigger_unregister_simple(ledtrig_network);
+}
+
+module_init(ledtrig_network_init);
+module_exit(ledtrig_network_exit);
+
+MODULE_AUTHOR("Florian Fainelli <florian@openwrt.org>");
+MODULE_DESCRIPTION("LED Network Activity trigger");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 88afcef..ed3774e 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -110,4 +110,10 @@ extern void ledtrig_ide_activity(void);
 #define ledtrig_ide_activity() do {} while(0)
 #endif
 
+#ifdef CONFIG_LEDS_TRIGGER_NETWORK_ACT
+extern void ledtrig_network_activity(void);
+#else
+#define ledtrig_network_activity() do {} while(0)
+#endif
+
 #endif		/* __LINUX_LEDS_H_INCLUDED */
diff --git a/net/core/dev.c b/net/core/dev.c
index 4317c1b..9423b26 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -116,6 +116,7 @@
 #include <linux/dmaengine.h>
 #include <linux/err.h>
 #include <linux/ctype.h>
+#include <linux/leds.h>
 
 /*
  *	The list of packet types we will receive (as opposed to discard)
@@ -1451,6 +1452,8 @@ int dev_queue_xmit(struct sk_buff *skb)
 gso:
 	spin_lock_prefetch(&dev->queue_lock);
 
+	ledtrig_network_activity();
+
 	/* Disable soft irqs for various locks below. Also
 	 * stops preemption for RCU.
 	 */

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Network activity LED trigger

[jamal]

You know that you posted this exact message last time? ;->
And i responded here:
http://marc.info/?l=linux-netdev&m=117882888105536&w=2

cheers,
jamal

On Wed, 2007-23-05 at 23:02 +0200, Florian Fainelli wrote:
> Here comes a basic patch that adds a network led activity. It is not 
> configurable yet, but is enough to make a LED configured with 
> the "network-activity" trigger to blink on network activity.
> 
> Netdev people can probably comment on the place of ledtrig_network_activity(), 
> which is probably not adequate. Also the ledtrig_network_activity can be 
> network device specific for instance.
> 
> Signed-off-by: Florian Fainelli <florian.fainelli@int-evry.fr>