Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
12748 Discussions

Delayed ethernet packet processing (bug?)

Altera_Forum
Honored Contributor II
1,155 Views

As reported to bugzilla: 

 

If the priority of the ethernet driver thread is lower (higher# ) than the FreeBSD Network Thread, then the Network Thread can get prematurely woken up to process an incoming ethernet pkt before the packet is fully enqued. Specifically: 

 

if_ethersubr:ether_demux() calls schednetisr() (which wakes up network thread) prior to the pkt being enqued with that call to IF_ENQUEUE(). 

 

This might not be obvious because a subsequent incoming packet can (partially) process the queue. 

 

One solution is to make sure the thread priority of the ethernet driver Handler_RxEvent() is higher (lower# ) than the FreeBSD Network Thread (default 7). A kludge option is to call both: 

schednetisr(2/*or NETISR_IP*/); 

schednetisr(18/* or NETISR_ARP*/); 

after each recv packet is processed by the Handler_RxEvent() call.
0 Kudos
1 Reply
Altera_Forum
Honored Contributor II
452 Views

Actually, this seems to be a problem if any network thread calling select(), such as tftp and probably most others, are at a lower priority (higher# ) than the FreeBSD Network Thread.

0 Kudos
Reply