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

Reply via email to