diff --git a/TODO b/TODO
index 5303077948..6a7a2e5084 100644
--- a/TODO
+++ b/TODO
@@ -19,7 +19,7 @@ nuttx/:
   (8)  Kernel/Protected Build
   (3)  C++ Support
   (6)  Binary loaders (binfmt/)
- (12)  Network (net/, drivers/net)
+ (13)  Network (net/, drivers/net)
   (4)  USB (drivers/usbdev, drivers/usbhost)
   (0)  Other drivers (drivers/)
  (12)  Libraries (libc/, libm/)
@@ -1032,6 +1032,29 @@ o Network (net/, drivers/net)
   Status:      Open
   Priority:    Low
 
+  Title:       ETHERNET WITH MULTIPLE LPWORK THREADS
+  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 muliple LP threads, some
+               additional mechanism would have to be added to enforce that
+               serialization.
+
 o USB (drivers/usbdev, drivers/usbhost)
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
diff --git a/sched/Kconfig b/sched/Kconfig
index d8ab894691..728b3879d8 100644
--- a/sched/Kconfig
+++ b/sched/Kconfig
@@ -1220,7 +1220,17 @@ config SCHED_LPNTHREADS
 		This options is required to support, for example, I/O operations
 		that stall waiting for input.  If there is only a single thread,
 		then the entire low-priority queue processing stalls in such cases.
-		Such behavior is necessary to support asynchronous I/O, AIO (for example).
+		Such behavior is necessary to support asynchronous I/O, AIO (for
+		example).
+
+		CAUTION: Some drivers, such as most Ethernet drivers, use the work
+		queue to serialize network operations.  The will also use the low-
+		priority work queue if it is available.  If there are multiple low-
+		priority worker thread, then this can result in the loss of that
+		serialization.  There may be concurrent Ethernet operations running
+		on different LP threads and this could lead to a failure.  You may
+		need to visit the use of the LP work queue on your configuration
+		is you select CONFIG_SCHED_LPNTHREADS > 1
 
 config SCHED_LPWORKPRIORITY
 	int "Low priority worker thread priority"