[Click] click driver packet path

[Adam Greenhalgh]

Problem is not visable on a linux 2.4.26 kernel with the e1000-5x
driver and the latest click from cvs.

Adam

On 5/3/06, Adam Greenhalgh <a.greenhalgh at cs.ucl.ac.uk> wrote:
> 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
> >
> >
>