[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070828.220402.15268351.davem@davemloft.net>
Date: Tue, 28 Aug 2007 22:04:02 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: mandeep.baines@...il.com
Cc: hadi@...erus.ca, rick.jones2@...com, msb@...gle.com,
netdev@...r.kernel.org, grundler@...gle.com,
robert.olsson@....uu.se, venza@...wnhat.org
Subject: Re: pktgen terminating condition
From: Mandeep Singh Baines <mandeep.baines@...il.com>
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists