How to reduce CPU load while sending to Ethernet

[Altera_Forum]

I use Cyclone V development kit with no Ethernet connected to the FPGA. One Ethernet connected to HPS. 

I tested CPU load and data rate with simple program:  for(i1 = 0; i1 < i2; i1++) { sent_size += sendto(sock, buf_frame, packet_size, 0, (struct sockaddr *) &echoclient, sizeof(echoclient)); //usleep(sleep_us); /// commented to test max rate, uncommented to reduce CPU load }   I've get 86.4 MB/s with packets 8192 B and 100 % CPU load. But I need CPU for others tasks. So, I've uncomment usleep(sleep_us) and got with sleep_us = 450, packet_size=8192 only 13.56 MB/s with 17 % CPU. 17 % CPU load is too much, 14 MB/s is too few.  Is it possible to send more data for less CPU time on HPS of Cyclone V SoC ?

[Altera_Forum]

Did you verify you're transmitting Jumbo frames?

[Altera_Forum]

The LAN where device is connected has MTU = 1500

[Altera_Forum]

Fix that and re-test.

[Altera_Forum]

It is desirable to avoid the restrictions that MTU is differ from commonly acceptable.

[Altera_Forum]

--- Quote Start ---  It is desirable to avoid the restrictions that MTU is differ from commonly acceptable.  --- Quote End ---    Your original question in your original post was:   --- Quote Start ---    Is it possible to send more data for less CPU time on HPS of Cyclone V SoC ?    --- Quote End ---    The answer to that question is: yes, by sending fewer but larger packets.  Your current test is sending (6) 1500b packets instead of (1) 8192b packet, so your processor overhead is 6x what it needs to be.

[Altera_Forum]

--- Quote Start ---  Your original question in your original post was:   The answer to that question is: yes, by sending fewer but larger packets.  Your current test is sending (6) 1500b packets instead of (1) 8192b packet, so your processor overhead is 6x what it needs to be.  --- Quote End ---    I'm not a Linux guru or anything, but I thought the stmmac driver included DMA support, so that a non-blocking socket to ethernet should be able to reduce overhead. I haven't looked in to it in any depth, but it would make sense. To reduce the CPU load on such a tight loop, though, you'd need some sort of select event that triggers when the driver is finished sending, with the thread sleeping in between (pthread)