Hello,
I have been evaluating the performance of a 10 gigabit adapter. It
provides a mode of receive data placement to memory through DMA called
"3 buffer mode". A receive packet is scattered into three buffers. The
ethernet header is in the first buffer, the tcp/ip header is in the
second buffer(if ip header, otherwise rest in 3rd), and the payload is
in 3rd buffer. I have created a skb with two additional fragments,
the ethernet header is contained in the skb itself, the first fragment
contains the ip header, the seocnd the payload.
It seems linux stack can't handle the fragmented buffers in the receive
path. Here is my finding, please correct me if I am wrong.
1) Upon receive interrupt the device driver interrupt handler calls
netif_rx(), after adjusting the skb->data (eth_type_trans()) for the
ethernet header. The routine queues the skb in the
softnet_data[]->input_pkt_queue
and raises the soft interrupt, NET_RX_SOFTIRQ.
2) The soft interrupt calls net_rx_action() to dequeue a skb from
queue->input_pkt_queue, initialize
skb->h.raw = skb->nh.raw = skb->data
and call appropriate protocol receive routine.
The network header has to lie just after the ethernet header, otherwise
skb->h.raw = skb->nh.raw = skb->data would be meaningless. The call to
eth_type_trans() in the driver puts the pointer skb->data just after
the ethernet header.
If all the protocol headers in the skb could be assigned in the device
driver, then probably fragmented skb in receive path would work. But the
driver would have to decode packet type. That would not a good thing to
do.
Any comment?
Kallol
--
--
NucleoDyne Corporation
nucleon@nucleodyne.com
www.nucleodyne.com
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
