[Click] click driver packet path

[Beyers Cronje]

Interesting. Hands up who wants to track down this bug. :)

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