[GitHub] [incubator-nuttx] v01d opened a new issue #3378: ETHERNET WITH MULTIPLE LPWORK THREADS

[GitBox <gi...@apache.org>]

v01d opened a new issue #3378:
URL: https://github.com/apache/incubator-nuttx/issues/3378


   ```
     Description: Recently, Ethernet drivers were modified to support multiple
                  work queue structures.  The question was raised: "My only
                  reservation would be, how would this interact in the case of
                  having CONFIG_STM32_ETHMAC_LPWORK and CONFIG_SCHED_LPNTHREADS
                  > 1? Can it be guaranteed that one work item won't be
                  interrupted and execution switched to another? I think so but
                  am not 100% confident."
   
                  I suspect that you right.  There are probably vulnerabilities
                  in the CONFIG_STM32_ETHMAC_LPWORK with CONFIG_SCHED_LPNTHREADS
                  > 1 case.  But that really doesn't depend entirely upon the
                  change to add more work queue structures.  Certainly with only
                  work queue structure you would have concurrent Ethernet
                  operations in that multiple LP threads; just because the work
                  structure is available, does not mean that there is not dequeued
                  work in progress.  The multiple structures probably widens the
                  window for that concurrency, but does not create it.
   
                  The current Ethernet designs depend upon a single work queue to
                  serialize data.  In the case of multiple LP threads, some
                  additional mechanism would have to be added to enforce that
                  serialization.
   
                  NOTE:  Most drivers will call net_lock() and net_unlock() around
                  the critical portions of the driver work.  In that case, all work
                  will be properly serialized.  This issue only applies to drivers
                  that may perform operations that require protection outside of
                  the net_lock'ed region.  Sometimes, this may require extending
                  the netlock() to be beginning of the driver work function.
   
     Status:      Open
     Priority:    High if you happen to be using Ethernet in this configuration.
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org