[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] NetClientInfo::can_receive change notification and its purp
From: |
Max Filippov |
Subject: |
[Qemu-devel] NetClientInfo::can_receive change notification and its purpose |
Date: |
Sun, 2 Feb 2014 05:47:31 +0400 |
Hello,
is there any way to notify networking core that adapter's
NetClientInfo::can_receive return value is about to change from 0 to 1?
I'm trying to talk to DHCP server from the recent (2014.01) u-boot running
in the xtensa system emulation over the tap interface. On the guest I see
the following picture (lines marked **...** are printed from the qemu):
U-Boot> dhcp
**open_eth_can_receive: 0**
**open_eth_can_receive: 0**
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
Retry count exceeded; starting again
ethoc
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
Retry count exceeded; starting again
^C
**open_eth_can_receive: 1**
**open_eth_can_receive: 1**
The u-boot driver enables packet reception on the network adapter just
before it starts sending packets, but on the networking core doesn't check
that NetClientInfo::can_receive has changed until I press ^C to interrupt
it. Then it receives some of the pending packets, but throws them away.
On the host side I see that DHCP server replies immediately.
When I remove NetClientInfo::can_receive callback from my network
adapter and throw away packets that cannot be received in the
NetClientInfo::receive callback it all works well. So I've got two questions:
- is there any way to push NetClientInfo::can_receive update to the
network core?
- wouldn't it be more correct to emulate real hardware more closely:
always be ready to receive a packet, but throw it away if there's e.g.
no buffers or the receiver is disabled?
--
Thanks.
-- Max
- [Qemu-devel] NetClientInfo::can_receive change notification and its purpose,
Max Filippov <=