netdev - Re: pktgen question

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 PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

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

Date:	Mon, 24 Sep 2007 11:02:36 -0700
From:	Rick Jones <rick.jones2@...com>
To:	Ben Greear <greearb@...delatech.com>
Cc:	Steve Wise <swise@...ngridcomputing.com>, hadi@...erus.ca,
	Evgeniy Polyakov <johnpol@....mipt.ru>, netdev@...r.kernel.org,
	Robert Olsson <Robert.Olsson@...a.slu.se>
Subject: Re: pktgen question

>> Perf-wise, you could clone the skbs up front, then deliver them to the 
>> nic in a tight loop.  This would mitigate the added overhead 
>> introduced by calling skb_clone() in the loop doing transmits...
> 
> That only works if you are sending a small number of skbs.  You can't 
> pre-clone several minutes worth of 10Gbe traffic
> with any normal amount of RAM.

Does pktgen really need to allocate anything more than some smallish fraction 
more than the depth of the driver's transmit queue?

Of course, even that won't fit in the L1 cache of a processor, so if one is 
really just trying to max-out the NIC it might still have too much overhead, but 
then does pktgen+driver et al actually fit in an L1 cache?

rick jones
-
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