On Thu, Jun 27, 2013 at 12:33 AM, Steve Wise <sw...@opengridcomputing.com> wrote: > On 6/26/2013 4:13 PM, Or Gerlitz wrote: >> On Wed, Jun 26, 2013 at 10:56 PM, Hefty, Sean <sean.he...@intel.com>
>>>> Steering rules processing order is according to rules priority. The user >>>> sets the 12 low-order bits from the priority field and the remaining >>>> 4 high-order bits are set by the kernel according to a domain the >>>> application or the layer that created the rule belongs to. Lower >>>> priority numerical value means higher priority. >>> Why are bit fields being exposed to the user in this way? >> Yes, this is probably not general enough. So what would you suggest, >> use a more integral division? e.g 16 bits for priority and 16 bits for >> location? > If the kernel driver is setting the "location", whatever that is, why would > the application need access to it? IE isn't a priority field enough to > allow the application provide an ordering/prioritization to the rules? I wasn't accurate, the idea is that per domain we allow the app to set the rule priority, but the actual priority towards the HW is made of the provided prioriry X domain, where different domains have different priorities along the order set by the verbs header file see enum ib_flow_domain -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
