[Click] click driver packet path

[Beyers Cronje]

Hi Adam,

I was wanting to reply to your previous post on the mailing list, but have
only gotten back from holiday yesterday. In short I still havent gotten a
stable polling implementation on 2.6 yet :(

>From the investigation I've done it appears that when Linux transmits
packets it does not go through the interrupt routine as you suspected, but
instead Linux calls 'netdev->hard_start_xmit'  which maps to
e1000_xmit_frame in e1000_main.c

The problem with interrupts being re-enabled while polling is active only
occurs after the driver receives a transmit hang. This occurs after the
driver calls e1000_tx_timeout_task which in turn calls e1000_up where
interrupts are enabled again. e1000_up should theoretically only re-enable
interrupts iff polling is not currently enabled, which it does not at this
stage.

But this is not the main bug, as we need to figure out why the transmit hang
occurs in the first place, and as this occurs before interrupts are
re-enabled it points to another more serious bug.

Regards

Beyers Cronje




On 4/27/06, Adam Greenhalgh <a.greenhalgh at cs.ucl.ac.uk> wrote:
>
> hi
>
> I'm playing with the e1000 driver and am trying to get it to work in
> polling mode with the 2.6 kernel. I'm seeing driver timeouts when
> sending packets from the local host because local host packets seem to
> be by passing the click part of the driver and are being delivered by
> the interrupt portion of the driver which I think is causing a race
> condition.
>
> Hence my question is this, which path should local packets follow when
> they are going to leave from an external interface ? My suspision is
> that they should not follow the interupt path if possible.
>
> Adam
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>