On Mon, Jul 20, 2015 at 06:12:09PM +0100, Stefan Hajnoczi wrote:
> On Thu, Jul 02, 2015 at 01:39:16PM +0100, Stefan Hajnoczi wrote:
> > On Tue, Jun 30, 2015 at 10:42:37AM +0800, Fam Zheng wrote:
> > > This is necessary because once we return false from .can_receive, we
> > > need to flush the queue when the .can_receive conditions become true
> > > again, (for example when more buffer is available).
> > >
> > > We can rely on net_rx_packet (which checks the same conditions) to drop
> > > the packet if the device is not ready, so drop net_xen_info.can_receive.
> >
> > This patch changes behavior:
> >
> > Previously can_receive() false meant packets are queued.
> >
> > Now those same conditions result in net_rx_packet() returning -1, so
> > packets are discarded.
> >
> > In order to keep the spirit of the queuing mechanism - where we tell a
> > sender to hold off until more rx buffers become available - I think the
> > following line in net_rx_packet() needs to be changed:
> >
> > if (rc == rp || RING_REQUEST_CONS_OVERFLOW(&netdev->rx_ring, rc)) {
> > xen_be_printf(&netdev->xendev, 2, "no buffer, drop packet\n");
> > return -1; <-- this should be changed to return 0
> > }
> >
> > That change assumes that net_event()'s flush is always called when the
> > rx ring gets more free space.
> >
> > Any thoughts from Xen folks?
>
> Ping?Need input from Xen developers. Ping?
pgp1oD0mETHph.pgp
Description: PGP signature
