|
From: | Jason Wang |
Subject: | Re: [PATCH v3 2/2] net: tulip: add .can_recieve routine |
Date: | Tue, 17 Mar 2020 13:50:06 +0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
On 2020/3/17 上午2:01, P J P wrote:
Hello Stefan, Jason, +-- On Fri, 6 Mar 2020, Stefan Hajnoczi wrote --+ | > +static int | > +tulip_can_receive(NetClientState *nc) | > +{ | > + TULIPState *s = qemu_get_nic_opaque(nc); | > + | > + if (s->rx_frame_len || tulip_rx_stopped(s)) { | > + return false; | > + } | > + | > + return true; | > +} | | Are the required qemu_flush_queued_packets() calls in place so that | packet transfer wakes up again when .can_receive() transitions from | false to true? Yes, qemu_flush_queued_packets() calls are in tulip_write(). Do we need to call tulip_can_receive() before each call?
Probably not, just need to make sure the check in tulip_rx_stopped(s) matches the action that triggers qemu_flush_queued_packets() in tulip_write() is sufficient.
This to make sure net core can restore the receiving. Btw, what's the point of checking rx_frame_len here? Thanks
Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
[Prev in Thread] | Current Thread | [Next in Thread] |