All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Cc: "Keir (Xen.org)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim (Xen.org)" <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Ian Jackson <Ian.Jackson@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing
Date: Mon, 4 Jan 2016 15:19:20 -0500	[thread overview]
Message-ID: <20160104201920.GA15307@char.us.oracle.com> (raw)
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD02F715A10@AMSPEX01CL01.citrite.net>

> > You've put the consumer values into the shared page. I'd rather not have
> > to scrutinize your shared ring implementation for other security bugs.
> > Similarly, if there's another security issues like XSA-155 I'd rather
> > not have to look at another non-standard shared ring implementation.
> 
> Ok. That's a good enough reason. I'll come up with a new prototype.

Could I suggest that you make this a more generic one? That is not
just limited to network out of band - but other drivers could 
use it as well.


> 
> > 
> > IMO, it's you who should be presenting compelling reasons for /not/
> > using the standard infrastructure, not the other way around.
> > 
> 
> There is no 'standard' here though. There's convention, but that's a different thing. If we're going to have a 'no more variable size message protocols' policy than that needs writing down somewhere.
> 
>   Paul
> 
> > David
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

  reply	other threads:[~2016-01-04 20:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-23 10:06 [PATCH 0/3] public/io/netif.h: support for toeplitz hashing Paul Durrant
2015-12-23 10:06 ` [PATCH 1/3] public/io/netif.h: document transmit and receive wire formats separately Paul Durrant
2015-12-23 10:06 ` [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing Paul Durrant
2015-12-23 11:45   ` Andrew Cooper
2015-12-23 11:56     ` Paul Durrant
2015-12-23 13:27   ` David Vrabel
2016-01-04  9:37     ` Paul Durrant
2016-01-04 10:55       ` David Vrabel
2016-01-04 11:14         ` Paul Durrant
2016-01-04 11:18           ` David Vrabel
2016-01-04 11:21             ` Paul Durrant
2016-01-04 11:28               ` David Vrabel
2016-01-04 11:34                 ` Paul Durrant
2016-01-04 20:19                   ` Konrad Rzeszutek Wilk [this message]
2016-01-05  9:40                     ` Paul Durrant
2015-12-23 10:06 ` [PATCH 3/3] public/io/netif.h: document new extra info for passing hash values Paul Durrant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160104201920.GA15307@char.us.oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@citrix.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.