Who captures packets first - kernel or driver?

I am trying to send packets from one machine to another using tcpreplay 开发者_如何学Cand tcpdump.

If I write a driver for capturing packets directly from the NIC, which path will be followed?

1) N/w packet ----> NIC card ----> app (no role of kernel)

2) N/w packet -----> Kernel -----> NIC card ---> app

Thanks

It's usually in this order:

• NIC hardware gets the electrical signal, hardware updates some of its registers and buffers, which are usually mapped into computer physical memory
• Hardware activates the IRQ line
• Kernel traps into interrupt-handling routine and invokes the driver IRQ handling function
• The driver figures out whether this is for RX or TX
• For RX the driver sets up DMA from NIC hardware buffers into kernel memory reserved for network buffers
• The driver notifies upper-layer kernel network stack that input is available
• Network stack input routine figures out the protocol, optionally does filtering, and whether it has an application interested in this input, and if so, buffers packet for application processing, and if a process is blocked waiting on the input the kernel marks it as runnable
• At some point kernel scheduler puts that process on a CPU and resumes is, application consumes network input

Then there are deviations from this model, but those are special cases for particular hardware/OS. One vendor that does user-land-direct-to-hardware stuff is Solarflare, there are others.

A driver is the piece of code that interacts directly with the hardware. So it is the first piece of code that will see the packet.

However, a driver runs in kernel space; it is itself part of the kernel. And it will certainly rely on kernel facilities (e.g. memory management) to do its job. So "no role of kernel" is not going to be true.