On Sun, Dec 13, 2015 at 3:56 PM, Liran Liss wrote:
>> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
>
>>
>> > You are pushing abstraction into provider code instead of handling it in a
>> generic way.
>>
>> No, I am defining an API that *make sense* and doesn't
> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
>
> > You are pushing abstraction into provider code instead of handling it in a
> generic way.
>
> No, I am defining an API that *make sense* and doesn't leak useless details.
> Of course that doesn't force code duplication or
> No, I am defining an API that *make sense* and doesn't leak useless
> details. Of course that doesn't force code duplication or anyhting
> like that, just implement it smartly.
>
> I think mlx made a big mistake returning network_type instead of gid
> index, and I don't want to see that error
On Thu, Dec 10, 2015 at 09:58:51AM +0200, Moni Shoua wrote:
> > creating a horrible API, or requiring all vendors to implement a
> > network type flag.
> >
> Actually you haven't suggested anything yet besides a name to the function.
> I already said that calculating gid_index from wc and grh
> Eh? I think you've missed the point, there is no net device when
> looking at a wc.
>
> Look, here is a concrete direction:
>
> Replace all the crap in
> ib_init_ah_from_wc/get_sgid_index_from_eth/rdma_addr_find_dmac_by_grh
>
> with a straightforward
>
>rdma_dgid_index_from_wc(
>
On Mon, Dec 7, 2015 at 8:48 PM, Jason Gunthorpe
wrote:
> On Mon, Dec 07, 2015 at 08:34:43PM +0200, Moni Shoua wrote:
>> Well, just tell me how you want to discover gid_index when you poll
>> the WC out of the CQ.
>
> Hey, I'm not desiging this rocev2 stuff, this
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Look, here is a concrete direction:
>
> Replace all the crap in
> ib_init_ah_from_wc/get_sgid_index_from_eth/rdma_addr_find_dmac_by_
> grh
>
> with a straightforward
>
>rdma_dgid_index_from_wc(
>
On Wed, Dec 09, 2015 at 11:34:10AM +0200, Moni Shoua wrote:
> > Eh? I think you've missed the point, there is no net device when
> > looking at a wc.
> >
> > Look, here is a concrete direction:
> >
> > Replace all the crap in
> >
On Wed, Dec 09, 2015 at 09:38:21AM +, Liran Liss wrote:
> > But, it is not part of our verbs API, and I'd *strongly* encourage other
> > vendors and future hardware to simply return the gid index that the
> > hardware matched instead of requiring the software to try and guess after
> > the
>>
>> A17.4.5.1 UD COMPLETION QUEUE ENTRIES (CQES)
>> For UD, the Completion Queue Entry (CQE) includes remote address
>> information (InfiniBand Specification Vol. 1 Rev 1.2.1 Section
>> 11.4.2.1). For RoCEv2, the remote address information comprises the
>> source L2 Address and a flag that
On Tue, Dec 08, 2015 at 09:23:18AM +0200, Moni Shoua wrote:
> >> Now, when same gid value can be present in multiple entries you need
> >> an extra parameter to get distinguish between them - that would be
> >> the netwrok_type
> >
> > Eh? You are only worried about duplicates between rocev1 mode
On Mon, Dec 7, 2015 at 8:48 PM, Jason Gunthorpe
wrote:
> On Mon, Dec 07, 2015 at 08:34:43PM +0200, Moni Shoua wrote:
>> Well, just tell me how you want to discover gid_index when you poll
>> the WC out of the CQ.
>
> Hey, I'm not desiging this rocev2 stuff, this
On Mon, Dec 07, 2015 at 08:37:41AM +0200, Moni Shoua wrote:
> On Mon, Dec 7, 2015 at 8:34 AM, Jason Gunthorpe
> wrote:
> > On Mon, Dec 07, 2015 at 08:15:40AM +0200, Moni Shoua wrote:
> >
> >> What you have though is the sgid taken from the GRH that is scattered
>
Moni Shoua asked:
> but how? all you have in hand is the sgid which can appear several
> times in the GID table in different indices.
Step back and review the context.
Adding an extra field to the WC is *not* going to redesign the hardware.
Anything that software can do in the verbs
On Mon, Dec 07, 2015 at 08:34:43PM +0200, Moni Shoua wrote:
> Well, just tell me how you want to discover gid_index when you poll
> the WC out of the CQ.
Hey, I'm not desiging this rocev2 stuff, this is something the rocev2
community needs to sort out.
> Like I said, the sgid itself is in the
On Mon, Dec 7, 2015 at 8:19 PM, wrote:
> Moni Shoua asked:
>
>
>
>> but how? all you have in hand is the sgid which can appear several
>
>> times in the GID table in different indices.
>
>
> Step back and review the context.
>
> Adding an extra field to the WC is *not* going to
Well, just tell me how you want to discover gid_index when you poll
the WC out of the CQ.
Like I said, the sgid itself is in the GRH that is scattered to the
buffers in the receive queue. When ib_poll_cq() is called the pointer
to GRH is not passed so there is no way to determine the gid_index
On Sun, Dec 6, 2015 at 4:03 PM, Christoph Hellwig wrote:
> The ULPs couldn't really care less about the network type. The problem
In WC, ULPs care about network type as much as they care for dgid or port_num
So, network_type is indeed an information that is relevant only to
On Thu, Dec 03, 2015 at 04:20:50PM +, Liran Liss wrote:
> > From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
>
> > Subject: Re: [PATCH for-next V2 05/11] IB/core: Add rdma_network_type to
> > wc
> >
> > Bloating the WC with a field that's not
On Mon, Dec 07, 2015 at 08:15:40AM +0200, Moni Shoua wrote:
> What you have though is the sgid taken from the GRH that is scattered
> to the first 40/20 bytes of the receive WQE. This is not enough to
> determine the network type.
It is enough to discover the sgid index which will tell you the
On Mon, Dec 7, 2015 at 8:34 AM, Jason Gunthorpe
wrote:
> On Mon, Dec 07, 2015 at 08:15:40AM +0200, Moni Shoua wrote:
>
>> What you have though is the sgid taken from the GRH that is scattered
>> to the first 40/20 bytes of the receive WQE. This is not enough to
On Mon, Dec 7, 2015 at 8:02 AM, Jason Gunthorpe
wrote:
> Why? The sgid index must tell you the network type.
struct ib_wc doesn't have sgid or sgid_index field.
What you have though is the sgid taken from the GRH that is scattered
to the first 40/20 bytes of the
On Mon, Dec 7, 2015 at 11:32 AM, Jason Gunthorpe
<jguntho...@obsidianresearch.com> wrote:
> On Thu, Dec 03, 2015 at 04:20:50PM +, Liran Liss wrote:
>> > From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
>>
>> > Subject: Re: [PATCH for-next V2 05/1
Bloating the WC with a field that's not really useful for the ULPs
seems pretty sad..
--
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
On Thu, Dec 03, 2015 at 03:47:12PM +0200, Matan Barak wrote:
> From: Somnath Kotur
>
> Providers should tell IB core the wc's network type.
> This is used in order to search for the proper GID in the
> GID table. When using HCAs that can't provide this info,
> IB
On Thu, Dec 3, 2015 at 4:05 PM, Christoph Hellwig wrote:
> Bloating the WC with a field that's not really useful for the ULPs
> seems pretty sad..
Network header type is mandatory in order to find the GID type and get
the GIDs correctly from the header.
I realize ULPs might
26 matches
Mail list logo