netdev - Re: [Xen-devel] [RFC PATCH 12/13] xen-netfront: implement TX persistent grants

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <77896F5F-DC2C-4F2A-9BB3-CE5F404DCECC@neclab.eu>
Date:	Tue, 19 May 2015 10:20:47 +0000
From:	Joao Martins <Joao.Martins@...lab.eu>
To:	David Vrabel <david.vrabel@...rix.com>,
	"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"wei.liu2@...rix.com" <wei.liu2@...rix.com>,
	"ian.campbell@...rix.com" <ian.campbell@...rix.com>,
	"boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>
Subject: Re: [Xen-devel] [RFC PATCH 12/13] xen-netfront: implement TX
 persistent grants


On 18 May 2015, at 17:55, David Vrabel <david.vrabel@...rix.com> wrote:
> On 12/05/15 18:18, Joao Martins wrote:
>> Instead of grant/revoking the buffer related to the skb, it will use
>> an already granted page and memcpy  to it. The grants will be mapped
>> by xen-netback and reused overtime, but only unmapped when the vif
>> disconnects, as opposed to every packet.
>> 
>> This only happens if the backend supports persistent grants since it
>> would, otherwise, introduce the overhead of a memcpy on top of the
>> grant map.
> [...]
>> --- a/drivers/net/xen-netfront.c
>> +++ b/drivers/net/xen-netfront.c
> [...]
>> @@ -1610,7 +1622,10 @@ static int xennet_init_queue(struct netfront_queue *queue)
>> 	for (i = 0; i < NET_TX_RING_SIZE; i++) {
>> 		skb_entry_set_link(&queue->tx_skbs[i], i+1);
>> 		queue->grant_tx[i].ref = GRANT_INVALID_REF;
>> -		queue->grant_tx[i].page = NULL;
>> +		if (queue->info->feature_persistent)
>> +			queue->grant_tx[i].page = alloc_page(GFP_NOIO);
> 
> Need to check for alloc failure here and unwind correctly?
Sorry, I overlooked this check. I will fix that.

> Why NOIO?
May be I am misusing NOIO where I meant __GFP_WAIT.
Tough given we are under rtnl_lock() perhaps GFP_ATOMIC should be used instead.--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html