netdev - Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring support.

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: <1328008648.5553.81.camel@leeds.uk.xensource.com>
Date:	Tue, 31 Jan 2012 11:17:28 +0000
From:	Wei Liu <wei.liu2@...rix.com>
To:	Ian Campbell <Ian.Campbell@...rix.com>
CC:	<wei.liu2@...rix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring
 support.

On Tue, 2012-01-31 at 09:12 +0000, Ian Campbell wrote:
> On Mon, 2012-01-30 at 21:39 +0000, Konrad Rzeszutek Wilk wrote:
> 
> [...snip... please do consider trimming unnecessary quotes]
> 
> > > @@ -1496,50 +1523,105 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> > >               goto fail;
> > >       }
> > >
> > > -     txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> > > +     err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> > > +                        "max-tx-ring-page-order", "%u",
> > > +                        &max_tx_ring_page_order);
> > > +     if (err < 0) {
> > > +             info->tx_ring_page_order = 0;
> > > +             dev_info(&dev->dev, "single tx ring\n");
> > > +     } else {
> > > +             info->tx_ring_page_order = max_tx_ring_page_order;
> > > +             dev_info(&dev->dev, "multi page tx ring, order = %d\n",
> > > +                      max_tx_ring_page_order);
> > > +     }
> > > +     info->tx_ring_pages = (1U << info->tx_ring_page_order);
> > > +
> > > +     txs = (struct xen_netif_tx_sring *)
> > > +             dma_alloc_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> > > +                                &info->tx_ring_dma_handle,
> > > +                                __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
> > 
> > Hm, so I see you are using 'NULL' which is a big nono (the API docs say that).
> > But the other reason why it is a no-no, is b/c this way the generic DMA engine has no
> > clue whether you are OK getting pages under 4GB or above it (so 64-bit support).
> 
> Does this allocation even need to be physically contiguous? I'd have
> thought that virtually contiguous would be sufficient, and even then
> only as a convenience at either end to avoid the need for more
> complicated ring macros.
> 

I had a second thought about this, you're right. I just need to make
sure it is virtually contiguous in both frontend and backend, that's
sufficient.

Wei.

> Ian.
> 
> 


--
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