[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel]How does xen-4.0.0 net backend work


  • To: cc Luit <universalbillow@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Thu, 24 Feb 2011 14:48:27 +0000
  • Cc:
  • Delivery-date: Thu, 24 Feb 2011 06:49:25 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=NB5AIfsFgaAHCNpnlU0tBo+4jkGzn61R/O3eQ9YVGqg0TUQdSvzoT9cSJaeiVCE2Lq 1MOoq8wM1YasNsUsjmcpxc3Q5AIcS3km2MlO10tv0pbgbq6hSbpriP1eAS80KCR7CNFX xfCupsrbraNNvmSEU9NqpKS9fwSdcqPPVwFg0=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcvUMeT1gccq3JR+mU6Vgz8QzouHng==
  • Thread-topic: [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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.