Thirumalai Srinivasan wrote:
Garrett D'Amore wrote:
But if the calling context is broken (by use of a taskq for
instance), then the risks you describe go away. Since that calling
context is already broken, I just would like a guarantee that it will
*remain* so. Then I can get away with this kind of approach.
Otherwise I add a lot of complexity or an additional context switch
(taskq) into my drivers. (Multiple drivers suffer this problem.)
Even before the taskq is used, the mac layer may have to acquire some
mac lock
say M1. Now if you are already holding a driver lock D1, the ordering
is D1 -> M1.
This imposes a requirement that we don't have M1 -> D1 anywhere in the
code.
So this becomes an exception to the general rule that locks may be
held across layers
in the downcall, and you have to filter out M1 -> D1. Using a taskq
in the driver instead,
avoids the exception itself. As the number of exceptions increase, the
locking becomes
unmanageable.
I understand this. But in this particular case, the lock M1 is a leaf
lock, all the locks are safe. And it would, IMO, be a bad idea to
change this part of nemo.
And yes, my suggestion does add a small amount of complexity to the
*rules* for drivers (an exception for a few mac_xxx_update entry
points), but the gain is the removal of significant complexity or
additional context switches in the device drivers.
Sure, we can look at that, and try to work out just this one case of
mac_xxx_update,
to the extent possible, but please don't make any assumptions based on
the current
implementation, and try to extend this in all generality.
Of course I'm not making assumptions. That's why I'm asking for an
exception to be made in this one case. I think the mac_xxx_update
functions are a logical case for this, and a few drivers will be
benefit, at least, with no real risks to nemo. So in this case I see
only upside.
Obviously for other upcalls, *especially* mac_rx(), this is not true,
and it would be ludicrous (IMO) for me to suggest that it should be made
to be safe as well.
I'll trade complexity in the framework for elimination of that
complexity in drivers (repeated across multiple drivers.)
To an extent yes, but not to the extent that it becomes impossible to
maintain the framework.
Of course. But in this case, no complexity is actually being increased
in the framework. Only a reasonable promise that the current reasonable
asynchronous disassociated implementation of mac_xxx_update be retained.
Believe me, if I could see any compelling reason to break that promise
in the framework, I wouldn't be asking for it. But the code paths we
are talking about are all off the hot code paths, and the simplification
actually shortens and simplifies some hot-path code for device drivers,
so its all upside _in this particular case_. I'm not asking for a
general rule, only a specific exception for mac_tx_update and
mac_link_update. (And even mac_link_update might not really be as
important, but mac_tx_update will save a lot of complexity in e.g. my
hme -> gldv3 port.)
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
