Linux Virtualization - Jan 2014 - [PATCH net-next 2/3] virtio-net: use per-receive queue page frag alloc for mergeable bufs

On Thu, Dec 26, 2013 at 01:28:58PM -0800, Michael Dalton
wrote:
> On Mon, Dec 23, 2013 at 11:37 AM, Michael S. Tsirkin <mst at
redhat.com> wrote:
> > So there isn't a conflict with respect to locking.
> >
> > Is it problematic to use same page_frag with both GFP_ATOMIC and with
> > GFP_KERNEL? If yes why?
> 
> I believe it is safe to use the same page_frag and I will send out a
> followup patchset using just the per-receive page_frags.
Seems easier to use it straight away I think.
> For future
> consideration, Eric noted that disabling NAPI before GFP_KERNEL
> allocs can potentially inhibit virtio-net network processing for some
> time (e.g., during a blocking memory allocation or preemption).
> 
> Best,
> 
> Mike
Interesting. But if we can't allocate a buffer how can we
do network processing?

If we can reproduce the problem, we can maybe move
allocation out of napi disabled section, but then
we'll need to add more locking.

On Thu, 2013-12-26 at 23:37 +0200, Michael S. Tsirkin wrote:
> Interesting. But if we can't allocate a buffer how can we
> do network processing?
How typical NIC drivers handle this case ?

Answer : nothing special should happen, we drop incoming traffic,
and make sure the driver recovers properly. (like not NULL deref or
crazy things like that)

Why virtio_net should be different ?
> 
> If we can reproduce the problem, we can maybe move
> allocation out of napi disabled section, but then
> we'll need to add more locking.
More exactly, use appropriate locking ;)

On Thu, Dec 26, 2013 at 02:00:58PM -0800, Eric Dumazet
wrote:
> On Thu, 2013-12-26 at 23:37 +0200, Michael S. Tsirkin wrote:
> 
> > Interesting. But if we can't allocate a buffer how can we
> > do network processing?
> 
> How typical NIC drivers handle this case ?
> 
> Answer : nothing special should happen, we drop incoming traffic,
> and make sure the driver recovers properly. (like not NULL deref or
> crazy things like that)
> 
> Why virtio_net should be different ?
Basically yes, we could start dropping packets immediately
once GFP_ATOMIC allocations fail and repost the buffer to host,
and hope memory is available by the time we get the next interrupt.
But we wanted host to have visibility into the fact that
we are out of memory and packets are dropped, so we did not want to
repost.
If we don't repost how do we know memory is finally available?
We went for a timer based workqueue thing.
What do you suggest?


> > 
> > If we can reproduce the problem, we can maybe move
> > allocation out of napi disabled section, but then
> > we'll need to add more locking.
> 
> More exactly, use appropriate locking ;)
>