[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: |
Peter Crosthwaite |
Subject: |
Re: [Qemu-devel] [QEMU RFC 0/2] Spying on Memory to implement ethernet can_recieve() |
Date: |
Mon, 18 Feb 2013 17:36:43 +1000 |
+Kuo-Jung Su
The same issue is present in the under review Faraday ethernet device model.
Regards,
Peter
On Mon, Jan 28, 2013 at 12:20 AM, Anthony Liguori <address@hidden> wrote:
> Peter Crosthwaite <address@hidden> writes:
>
>> 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.
>
> I don't think there's anything special here. This comes down to: how
> can a device emulation provide flow control information to the backend?
>
> There are two ways this works today in QEMU. Most devices have some
> sort of mailslot register that's notified when RX buffers are added to
> the descriptor ring. From that, you call qemu_flush_queued_packets() to
> start the flow again. virtio-net is an example of this.
>
> If there is truly no notification when adding descriptors, the only
> option is to use a timer to periodically poll the descriptor ring. This
> is how our USB controllers work.
>
> Trying to write-protect memory is a losing battle. You'll end up with a
> timer anyway to avoid constantly taking page faults.
>
> Regards,
>
> Anthony Liguori
>
>>
>> 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
>
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-devel] [QEMU RFC 0/2] Spying on Memory to implement ethernet can_recieve(),
Peter Crosthwaite <=