|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel]How does xen-4.0.0 net backend work
On 24/02/2011 13:48, "cc Luit" <universalbillow@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|