From: Mandeep Singh Baines <[EMAIL PROTECTED]>
Date: Tue, 28 Aug 2007 21:43:52 -0700

> Here is what the datasheet has to say about TxIdle:
> 
> "This event is signaled when the transmit state machine enters the idle state 
> from a non-idle state. This will happen whenever the state machine encounters
> an "end-of-list" condition (NULL link field or a descriptor with OWN clear)."
> 
> I interpret this to mean that the interrupt gets generates after a packet
> is transferred to the TFIFO on the NIC and the next packet in the ring is
> NULL. 
> 
> This interrupt gets generates less often then TxOK which gets generated
> after every completed packet transmit. So I'm thinking that maybe the
> driver was written to use this interrupt instead of TxOK for this reason.
> Really just my speculation.

I see, so essentially it doesn't interrupt until the entire TX
ring is empty and has been sent onto the wire.

Yes, this would be exactly sub-optimal for pktgen or in fact any
application :-)

It seems that the INTbit in the TX descriptor status of the
SIS190 can be an interrupt trigger.  In that case, a reasonable
and quite common scheme would be to set that bit every 1/4 of
the TX ring.  And also enable the TX idle interrupt.

So if the TX ring size is 8 entries and you received a set of
TX sends you'd set the interrupt status bits like this:

                TX descr interrupt bit

packet 0:       none
packet 1:       INTbit
packet 2:       none
packet 3:       INTbit
packet 4:       none
packet 5:       INTbit
packet 6:       none
packet 7:       INTbit

And you'd get 4 TX descriptor based interrupts, one for each INTbit
and probably free up 2 TX packets each time (or more if there is some
overlap).

The idle interrupt bit take care of the case where you have an
odd number of packets (say removing packet 7 in the trace above)
to make sure those sub-1/4 group of TX frames get freed up and
processed in a deterministic amount of time.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to