Walukiewicz, Miroslaw wrote:
Hello Steve,
I want to add a change preventing creation of the L2 RAW_QPT from user priviledge (uid = 0 will be able to do such operation)
What is the best place to do such change: ibv_create_qp in libibverbs(verbs.c)
or allowing to decide for NIC vendors if th
: [PATCH v2] libibverbs: add path record definitions to sa.h
Walukiewicz, Miroslaw wrote:
> Hello Steve,
>
> Do you plan some changes in the core code related to RAW_QPT?
>
>
The only changes I see needed to the kernel core is the mcast change you
already proposed to allow mcas
>Also, There is a rdmacm kernel change to pass up iwarp L2 addresses once
>a cm_id has resolved the addresses. I posted it earlier and I think
>Sean is going to integrate it for 2.6.36.
I believe that the patch you posted earlier is sufficient for 2.6.35. I just
need to update my patch set for A
Steve Wise wrote:
Walukiewicz, Miroslaw wrote:
Hello Steve,
Do you plan some changes in the core code related to RAW_QPT?
The only changes I see needed to the kernel core is the mcast change
you already proposed to allow mcast attach/detach for RAW_ETY qps...
Also, There is a rdmacm
Walukiewicz, Miroslaw wrote:
Hello Steve,
Do you plan some changes in the core code related to RAW_QPT?
The only changes I see needed to the kernel core is the mcast change you
already proposed to allow mcast attach/detach for RAW_ETY qps...
Could you explain me better what means "p
f Of Steve Wise
Sent: Tuesday, May 18, 2010 4:04 PM
To: Roland Dreier
Cc: Hefty, Sean; linux-rdma
Subject: Re: [PATCH v2] libibverbs: add path record definitions to sa.h
Roland Dreier wrote:
> > Can you add the RAW_ETY qp type in this release as well?
>
> To be honest I haven't l
Roland Dreier wrote:
> Can you add the RAW_ETY qp type in this release as well?
To be honest I haven't looked at the iWARP datagram stuff at all. I'm
not sure overloading the RAW_ETY QP type is necessarily the right thing
to do -- it has quite different (never implemented) semantics in the IB
> Can you add the RAW_ETY qp type in this release as well?
To be honest I haven't looked at the iWARP datagram stuff at all. I'm
not sure overloading the RAW_ETY QP type is necessarily the right thing
to do -- it has quite different (never implemented) semantics in the IB
case. Is there any ove
Roland Dreier wrote:
thanks, applied this. Will roll a new libibverbs release early next week.
Can you add the RAW_ETY qp type in this release as well?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More major
thanks, applied this. Will roll a new libibverbs release early next week.
--
Roland Dreier || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a messag
>I can release an updated version of libibverbs (I have enough stuff
>pending that this is probably a good idea anyway). However could you do
>some autoconf stuff so librdmacm works against older libibverbs (but
>doesn't enable the stuff that can't be done without the missing stuff)?
>Or maybe it'
> I'd like to release a new version of librdmacm that can support the user
> space
> SA query feature in 2.6.33, which will also be part of OFED 1.5.2.
> Currently,
> there's a dependency on the path record definition being part of libibverbs.
> Do
> you have any opinions on the best wa
Roland,
I'd like to release a new version of librdmacm that can support the user space
SA query feature in 2.6.33, which will also be part of OFED 1.5.2. Currently,
there's a dependency on the path record definition being part of libibverbs. Do
you have any opinions on the best way to handle thi
Add definitions for path record wire definition. This
will be used by the librdmacm and ib_acm service, and is
exchanged with the kernel using the newer set and query
route functionality.
Signed-off-by: Sean Hefty
---
Change from v1:
Used ibv/IBV prefix to match rest of libibverbs.
I used/kept t
14 matches
Mail list logo