qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [QEMU RFC 0/2] Spying on Memory to implement ethernet c


From: Edgar E. Iglesias
Subject: Re: [Qemu-devel] [QEMU RFC 0/2] Spying on Memory to implement ethernet can_recieve()
Date: Sat, 26 Jan 2013 22:30:18 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Jan 26, 2013 at 12:18:29PM -0800, Peter Crosthwaite wrote:
> Hi All,
> 
> Have a bit of a tricky question about ethernet controllers. We are 
> maintaining two ethernet controllers the cadence GEM and the Xilinx AXI 
> Ethernet both of which are scatter gather (SG) DMA capable. The issue comes 
> about when trying to impelement the can_recieve() function for each.
> 
> For the sake of background, the ethernet can_recieve() function is used by 
> net devices to signal to the net API that it cant consume data. As QEMU 
> network interfaces are infinately faster than real hardware you need to 
> implement this function to insulate against mass packet droppage. The 
> can_recieve has no real hardware analog, the network devices would just drop 
> the packets (but the packets would be comming at a much slower rate).
> 
> For most devices, the return of this function is dependant on internal state 
> of the device. However, for SGDMA, whether or not you can receive is 
> dependent on the state of the SGDMA buffer descriptors, which are stored in 
> RAM. So to properly implement can_receive() we need to spy on the contents of 
> memory, to see if the next descriptor is valid. This is not too hard. The 
> hard part is monitoring the descriptor for change after you have returned 
> false from can recieve() so you can tell the net layer you are now ready. 
> Essentially, you need to watch memory and wakup when the cpu writes to the 
> magic address. Patch 1 is a hackish first attempt at this for the cadence 
> GEM, using the Memory API.
> 

Hi Peter,

AFAIK, this flow control is typically part of the stream interface towards the 
DMA and based on internal state from the DMA.
For example, add something like can_push() to stream.c and have the axidma.c 
call that function when it's internal state changes wrt beeing able to receive 
data.
For xilinx_axidma.c, can_push() would propagate the running and idle state: 

can_push(stream_running(s) && !stream_idle(s));

from various points were this state changes.

I can imagine that there is hw without this kind of flow control but I don't 
think these MACs & DMA's are like that.

Cheers,
Edgar


> The alternative to this is to impelement timing for the ethernet device, 
> which is truer to the real hardware. Throttle the ethernet trasffic based on 
> wire speed, not the state of the ethernet controller. Ive had an attempt at 
> this for the AXI Ethernet (Patch 2) but a proper solution to this would be to 
> implement this wire side (in the net layer) rather than device side.
> 
> Peter Crosthwaite (2):
>   cadence_gem: Throttle traffic using buffer state
>   xilinx_axienet: Model timing.
> 
>  hw/cadence_gem.c    | 75 
> ++++++++++++++++++++++++++++++++++++++++++++---------
>  hw/xilinx_axienet.c | 16 ++++++++++--
>  2 files changed, 77 insertions(+), 14 deletions(-)
> 
> -- 
> 1.7.12.1.396.g16eed7c
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]