[Click] click driver packet path

Adam Greenhalgh a.greenhalgh at cs.ucl.ac.uk
Wed May 3 09:01:08 EDT 2006


Beyers,

I hope you had a good vacation.

Have you been watching the e1000 list recently (or over the past few
months) ? There have been numerous problems with the driver in
general, ok mainly in the 6.X and 7.X branches of the code but it
isn't entirely clear as to what the actual cause is, but the driver is
look like it might be one cause of the problems. We are just building
a 32bit os image with a 2.4 kernel to see if we see the same problems
here as we do on the 2.6 kernel with the same hardware. I'll report
back soon.

You are right about the packet flow, this raises the question as to
which path the host packets should follow when the driver is in
polling mode ? Show they go through the click routines or through
these "native" routines ?

I am in two minds as to whether to push on with the 5.x/6.x branch of
the driver or try and move to the 7.x branch and take advantage of the
fixes the intel guys are doing.

Adam

Adam

On 5/3/06, Beyers Cronje <bcronje at gmail.com> wrote:
> 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
>
>



More information about the click mailing list