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@lists.xensource.com
http://lists.xensource.com/xen-devel
On 24/02/2011 13:48, "cc Luit" <universalbillow@gmail.com> wrote:> > 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 ?The netback driver processes packets on behalf of other VMs running on the host. The ''tx'' and ''rx'' naming scheme in netback is used from the point of view of the client VMs -- when a VM transmits a packet, netback processes it via net_tx_action, and injects it into domain-0 kernel''s network stack for forwarding (usually via a software ethernet bridge to a physical network interface). Netif_Rx() is nothing more than the interface provided for network drivers to stuff packets up into the kernel''s network stack. Note that this confusion also arises on the receive path (from the p.o.v. Of other VMs) -- packets get ''transmitted'' out of dom0 kernel''s network stack, into netback, and thence into the receive buffers of the relevant virtual machines.> 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?Via the normal dom0 kernel network stack. Usually the netback interface is registered to an etherbridge, and packets get transferred between netback and the physical interface via the etherbridge. -- Keir> I''m not sure if I have expressed my questions clearly, it not, please tell me, > I appreciate your help. > > Thanks in advance:)_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel