[REVIEW/TEST] polling(4) changes
dima
_pppp at mail.ru
Fri Oct 7 02:29:02 PDT 2005
> d> Seems to be a first considerable step regarding the ideas discussed in March :)
> d> But, my idea about the separate locking of each interface dissappeared from this implementation. mtx_poll is good to protect the pollrec array and other sensitive variables. But we could get advantage of SMP machines writing polling loops like this:
> d>
> d> for( i = 0; i < poll_handlers; ++i ) {
> d> mtx_lock( &iface_lock[i] );
> d> pr[i].handler(pr[i].ifp, POLL_ONLY, count);
> d> mtx_unlock( &iface_lock[i] );
> d> }
>
> What is the benefit here? The driver must have its own lock.
Well, consider the absense of the mtx_poll lock:
- mtx_lock( &mtx_poll );
for( i = 0; i < poll_handlers; ++i ) {
+ mtx_lock( &iface_lock[i] );
pr[i].handler( pr[i].ifp, POLL_ONLY, count );
+ mtx_unlock( &iface_lock[i] );
}
- mtx_unlock( &mtx_poll );
So, several kernel threads in an SMP machine can poll different interfaces simultaneously. And mtx_lock should only be used in ether_poll_[de]register().
More information about the freebsd-arch
mailing list