On 28 Dec 2004 08:31:57 -0500, jamal <[EMAIL PROTECTED]> wrote: > On Fri, 2004-12-24 at 11:10, Eric Lemoine wrote: > > > Yes but requiring drivers to release a lock that they should not even > > be aware of doesn't sound good. Another way would be to keep > > dev->queue_lock grabbed when entering start_xmit() and let the driver > > drop it (and re-acquire it before it returns) only if it wishes so. > > Although I don't like this too much either, that's the best way I can > > think of up to now... > > I am not a big fan of that patch either, but i cant think of a cleaner > way to do it. > The violation already happens with the LLTX flag. So maybe a big warning > that says "Do this only if you driver is LLTX enabled". The other way to > do it is put a check to see if LLTX is enabled before releasing that > lock - but why the extra cycles? Driver writer should know.
Two (untested) patches implementing what I described above. The first pach (sch_generic.patch) keeps queue_lock held in qdisc_restart() when calling hard_start_xmit() of a LLTX driver. The second (sungem.patch) makes sungem release queue_lock after grabbing its private tx lock. Note that the modifications made to qdisc_restart() are not compatible with the current LLTX drivers. All LLTX drivers must be modified along sungem.patch's lines. Take sungem.patch as an example of how things must be done. Patches apply to current davem bk snapshot. -- Eric
sch_generic.patch
Description: Binary data
sungem.patch
Description: Binary data
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
