[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel]How does xen-4.0.0 net backend work
Hi, everyone. These days I was reading the code of xen/linux/drivers/xen/netback/netback.c and xen/linux/drivers/net/xen-netfront.c
in order to understand the control flow like how the domU transmit the packets from frontend to backend and then to the dom0 net-driver, but I came across some questions in netback.c.
after the frontend transmitted the packets, dom0 schedule to the net_tx_tasklet, which goes to the net_tx_action() function:
1409 static void net_tx_action(unsigned long unused) 1410 { 1411 unsigned nr_mops; 1412 int ret; 1413 1414 if (dealloc_cons != dealloc_prod)
1415 net_tx_action_dealloc(); 1416 1417 nr_mops = net_tx_build_mops(); 1418 1419 if (nr_mops == 0) 1420 return;
1421 1422 ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, 1423 tx_map_ops, nr_mops); 1424 BUG_ON(ret); 1425
1426 net_tx_submit(); 1427 } in the net_tx_submit() function, it finally goes to a code: 1394 netif_rx(skb);
so I'm curious why in the tx_submit there is a rx function? is the parameter skb the buffer that has been sent to the network? or it is the buffer that has not yet been sent? what is the netif_rx() function used to ?
Another question is: how the backend interact with the real dom0 driver? I cannot actually find the path like what I speculate: backend push the packet to a buffer where linux driver will poll and send it to the real DMA ring...(it is just what I guess the interactive path is@@), can anyone explain the detail of it?
I'm not sure if I have expressed my questions clearly, it not, please tell me, I appreciate your help. Thanks in advance:) -- - Luit @ Parallel Processing Institute, Fudan University _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |