[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54AD0F12E08D1541B826BE97C98F99F1EE6B67@NT-SJCA-0751.brcm.ad.broadcom.com>
Date: Tue, 9 Jan 2007 10:29:12 -0800
From: "Caitlin Bestler" <caitlinb@...adcom.com>
To: "Michael S. Tsirkin" <mst@...lanox.co.il>,
"Steve Wise" <swise@...ngridcomputing.com>
cc: netdev@...r.kernel.org, "Roland Dreier" <rdreier@...co.com>,
"Divy Le Ray" <divy@...lsio.com>, linux-kernel@...r.kernel.org,
"openib-general" <openib-general@...nib.org>
Subject: RE: [openib-general] [PATCH 1/10] cxgb3 - main header files
> -----Original Message-----
> From: openib-general-bounces@...nib.org
> [mailto:openib-general-bounces@...nib.org] On Behalf Of
> Michael S. Tsirkin
> Sent: Tuesday, January 09, 2007 5:57 AM
> To: Steve Wise
> Cc: netdev@...r.kernel.org; Roland Dreier; Divy Le Ray;
> linux-kernel@...r.kernel.org; openib-general
> Subject: Re: [openib-general] [PATCH 1/10] cxgb3 - main header files
>
> > We also need to decide on the ib_req_notify_cq() issue.
>
> Let's clarify - do you oppose doing copy_from_user from a
> fixed address passed in during setup?
>
> If OK with you, this seems the best way as it is the least
> controversial and least disruptive one.
>
To clarfiy my understanding of this issue:
A device MAY implement ib_req_notify_cq by updating
a location directly from user mode. Any of the techniques
that apply to other user allocated objects, such as
the Send Queue, can be applied here.
Even those the proposed changes would be about as
low impact and benign as possible, the fact that there
are valid solutions without an API changes leans heavily
towards using those solutions.
-
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