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
| ||
|
Date: Sun, 7 Jun 2015 13:04:23 +0100 From: Wei Liu <wei.liu2@...rix.com> To: Joao Martins <Joao.Martins@...lab.eu> CC: Wei Liu <wei.liu2@...rix.com>, "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "ian.campbell@...rix.com" <ian.campbell@...rix.com>, "david.vrabel@...rix.com" <david.vrabel@...rix.com>, "boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>, "konrad.wilk@...cle.com" <konrad.wilk@...cle.com> Subject: Re: [RFC PATCH 03/13] xen-netback: implement TX persistent grants On Wed, Jun 03, 2015 at 05:07:59PM +0000, Joao Martins wrote: [...] > > > > How much harder would it be to ref-count inflight grants? Would that > > simplify or perplex things? I'm just asking, not suggesting you should > > choose ref-counting over current scheme. > > > > In principle I favour simple code path over optimisation for every > > possible corner case. > > ref-counting the persistent grants would mean eliminating the check for > EBUSY on xenvif_pgrant_new, but though it isn’t that much of a simplification. > Right. > What would simplify a lot is if I grant map when we don’t get a persistent_gnt > in xenvif_pgrant_new() and add it to the tree there instead of doing on xenvif_tx_check_gop. > Since this happens only once for persistent grants (and up to ring size), I believe it > wouldn't hurt performance. > Yeah. Mapping page inside xenvif_tx_check_gop doesn't sound nice. > This way we would remove a lot of the checks in xenvif_tx_check_gop and > hopefully leaving those parts (almost) intact mainly to be used for grant > map/unmap case. The reason I didn’t do it because I wanted to reuse the > grant map code and thought that preference was given towards batching the > grant maps. But it looks that it definitely makes things more complicated > and adds more corner cases. > > The same goes for the RX case where this change would remove a lot of the code > for adding the grant maps (thus sharing a lot from the TX part) besides removing the > mixed initial grant copy + map. What do you think? > I couldn't really comment until I see the code. But in principle I think this is a step towards the right direction. Wei. > Joao -- 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
Powered by blists - more mailing lists