On Mon, Oct 15, 2018 at 12:28 PM, Joe Touch <[email protected]> wrote: > > > > > On 2018-10-15 12:13, Tom Herbert wrote: > > On Mon, Oct 15, 2018 at 12:06 PM, Templin (US), Fred L > <[email protected]> wrote: > > Hi Tom, > > ... > From what I saw when I was working with iperf3. By default, it uses 8KB > UDP datagram sizes when it runs on Ubuntu. By setting the UDP datagram > size to a smaller value (i.e., one that needs less IP fragmentation) it > shows > a performance decrease. By setting the UDP datagram size to a larger value > (i.e., one that needs more IP fragmentation) it shows a performance > increase. > > Yes, this because it's better to wake application once than mutiple > times for smaller packets. > > > Smaller packets have lower throughput because of many other per-packet > overheads which include the header length overhead relative to the payload > and setup costs for DMA and IP checksum, etc. > UDP is eight bytes overhead, IP fragmentation header is eight bytes. So fragmenting one UDP packet versus sending the equivalent packets as UDP datagrams have similar wire overhead (I belive the net difference is eight extra bytes for fragmentation). Stack procesing of UDP versus a fragment also should not particularly different. Both require a table lookup, but it's also true that much more effort will go into optimizing UDP than fragmentation because of much higher usage.
> The issue of waking the app matters less if using polling, which is more > typical than relying on interrupts for high-speed networking. There's still overhead, for instance each UDP message needs to be separately read, but then we also have recvmmsg that could address that. It's unlikely iperf uses that. I don't believe that host processing of the two scenarios should be particularly different if all the best API is used. I still intend on testing this soon. Tom > > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
