Peter Memishian wrote:
Unfortunately, I don't think it's possible to differentiate all three cases in the current interface for mi_tx().
If we could rework this interface a bit so that the tx routine never frees packets but only marks their status in the mblk somehow, then the caller (specifically DLS) could make decisions and do things with packets after the driver gives its result, and free them as appropriate. The problem is that the driver probably will want to free them asynchronously. This seems to need a callback from the MAC driver when it has accepted a packet and committed to its trasmission, but not yet initiated the process that could lead to an asynchronous freemsg, so that DLS has its opportunity to make any dups that it needs for loopback purposes. Maybe this is evidence that we're just doing queueing at the wrong point. If the MAC provider continuously provided a tx queue full/not-full indicator and always accepted everything given to it, instead of sometimes returning some packets unprocessed, we wouldn't have this problem. -=] Mike [=- _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org