[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
>
>