Question on using Linux as a router

Question on using Linux as a router

[Serge Goodenko]

Hi everybody!

I got the following question.

When I use linux as a router (via ip forwarding) what kernel variables (maybe some queues?) represent the closest analogue of usual hardware router input and output buffers? May this be, say, backlog queue or something else?

The things I need to get are the sizes and loads of that buffers during transmission.
I know about variables such as sk->sk_rcvbuf and sk->sk_rmem_alloc but they are not used during ip forwarding as the socket (i.e. sock structure) is not even being created for that purpose. As far as I understood these variables in sock structure are mostly used for tcp-level packet processing and they represent the values written in files like /proc/sys/net/core/wmem_default etc. (please correct me if that's wrong), but nevertheless maybe I also can use these values for "routing" buffers (i.e. on ip level)?

thanks in advance,
Servge
MIPT
Moscow, Russia

How does LED blinking work in e1000 driver?

[Tony Chung]

Hi,

Can someone explain how does LED blinking work in the e1000 driver?

For the copper version work, please verify my understanding:
1. The blinking of the four LEDs is control by the LEDCTL register 
through a 32 bit value. That is 8 bit per LED. This is already described 
in the Intel software 8454x developer manual.

2. When running “ethtool -p” , the current LEDCTL value will be saved. 
Then two different LEDCTL values (mode1 and mode2 ) will be calculated 
based on the EEPROM value (word offset at 0x4).

    * The e1000_led_on() will call LEDCTL register with mode2 value.
    * The e1000_led_off() will call LEDCTL register with mode1 value.
    * the e1000_led_on()/off() functions will be called alternatively
      based on a timer.
    * when stopped, the e100_led_cleanup() will restore the saved value
      back to the LEDCTL register.


The EEPROM data at word offset 0x4 (verify using “ethtool -e” ) is a16 
bit value controls the behavior of the 4 LEDs (4 bits each). They are 
defined in the file e1000_hw.h:
#define ID_LED_DEF1_DEF2 0x1
#define ID_LED_DEF1_ON2 0x2
#define ID_LED_DEF1_OFF2 0x3
#define ID_LED_ON1_DEF2 0x4
#define ID_LED_ON1_ON2 0x5
#define ID_LED_ON1_OFF2 0x6
#define ID_LED_OFF1_DEF2 0x7
#define ID_LED_OFF1_ON2 0x8
#define ID_LED_OFF1_OFF2 0x9

The defines correspond to which LED will be on/off or default during 
mode1 or mode2. e.g. ID_LED_ON1_OFF2 mean turn LED ON during mode 1 
while turn LED off during mode2.
ID_LED_DEF1_ON2 mean use default/original value during mode1 while turn 
LED on during mode2.

If the EEPROM value at word offset 0x4 is 0xFFFF or 0x0000, then the 
driver will use the default value 0x8911 which corresponds to:
LED0 is 0x1 (DEF1_DEF2)
LED1 is 0x1 (DEF1_DEF2)
LED2 is 0x9 (OFF1_OFF2)
LED3 is 0x8. (OFF1_ON2) so other LED3 will blink while LED0/LED1 behave 
whatever the original value was.


For the fiber version, the e1000 driver just clear/set the software 
defined PIN 0. Is there any document about this?
Actually, when I modified the driver to use the LEDCTL register as in 
the copper version, it can still blink the LEDs. Why bother with defined 
PIN0 at all? That is, can the driver simply use LEDCTL register alone?

Thanks.
- Tony