netdev - Re: pktgen terminating condition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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