thanks in advance if anybody can help me out.
i have read an article about freebsd protocol stack. it says that in freebsd,
network protocol stack can be processed either in the interrupt context, or in the application thread context. The interrupt context happens when the network interface card interrupts the host, the NIC's associated inbound protocol thread services the NIC and process received packets "up" the network stack.
For application thread context, when an application thread makes a socket-related system calls, the calling thread context is "borrowed" to carry out the protocol processing with the kernel.
Could anybody elaborate more about the "application thread context"?
Assume that in a multi-core system, an application thread context is being "borrowed" to carry out the TCP protocol processing within the kernel in CPU 0, at the same time, new incoming data (for the same TCP stream) interrupts another cpu (say cpu 1) and the invokes the interrupt handler. Because the TCP is being processing in the application thread context in cpu 0, due to TCP state consistency issues, CPU 1 can not perform TCP processing for the new incoming data at the moment. CPU 1 has to store the new incoming data (for the same tcp stream) somewhere and wait the "borrowed" application thread to process the new incoming data. Is my understanding correct?
thanks,
wenji
i have read an article about freebsd protocol stack. it says that in freebsd,
network protocol stack can be processed either in the interrupt context, or in the application thread context. The interrupt context happens when the network interface card interrupts the host, the NIC's associated inbound protocol thread services the NIC and process received packets "up" the network stack.
For application thread context, when an application thread makes a socket-related system calls, the calling thread context is "borrowed" to carry out the protocol processing with the kernel.
Could anybody elaborate more about the "application thread context"?
Assume that in a multi-core system, an application thread context is being "borrowed" to carry out the TCP protocol processing within the kernel in CPU 0, at the same time, new incoming data (for the same TCP stream) interrupts another cpu (say cpu 1) and the invokes the interrupt handler. Because the TCP is being processing in the application thread context in cpu 0, due to TCP state consistency issues, CPU 1 can not perform TCP processing for the new incoming data at the moment. CPU 1 has to store the new incoming data (for the same tcp stream) somewhere and wait the "borrowed" application thread to process the new incoming data. Is my understanding correct?
thanks,
wenji