Messages in this thread | | | Subject | Re: [ATM] first pass at fixing atm spinlock | Date | Tue, 18 Mar 2003 11:11:54 -0500 | From | chas williams <> |
| |
>good job, cleaning the ATM stuff up -- on the note below: I've been having lot >problems w/ the close and "dangeling" vccs, since in my scenarios traffic was >coming in AFTER the close. I tried to defer the destruction and it got rid of
what driver are you using? this seem like wrong behavior imho. the first part of close should stop the card from delivering anymore traffic on the particular vpi/vci. close should return after it is certain that no more traffic will arrive on said vpi/vci pair.
>Anyway, how about re-doing the VCC stuff mor in the way you did it for the >HE device driver - having an array, indexed by a pvc hash -- and one could eas
almost all the drivers walk the vcc list trying to find a vpi/vci pair. enough that there should be a real lookup that is hashed. however, some drivers (like the nicstar) keep an indexed array of vpi/vcc pointing to the approriate vcc.
>BTW: Have you addressed the difficulty that, depending on the ATM board, some >packet receives are handled while still in the IRQ and others (the newer/bette >ones always go through a tasklet?
that's really up the driver authors. convince the author to change to a tasklet. change it yourself. it shouldnt be too difficult in most cases. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |