On Mon, Jun 08, 2015 at 05:12:13PM +0300, Matan Barak wrote:
> +static struct net_device *mlx4_ib_get_netdev(struct ib_device *device, u8
> port_num)
> +{
This function is never referenced in this patch, so we get compile
warnings?
Warnings are not a huge deal, but you did compile test every pa
On Mon, Jun 08, 2015 at 05:12:08PM +0300, Matan Barak wrote:
> +unsigned long roce_gid_type_mask_support(struct ib_device *ib_dev, u8 port);
> +
What is all this gid_type_mask stuff about? rocev2?
> +unsigned long roce_gid_type_mask_support(struct ib_device *ib_dev, u8 port)
> +{
> + return
On Mon, Jun 08, 2015 at 05:12:10PM +0300, Matan Barak wrote:
> +static enum bonding_slave_state is_eth_active_slave_of_bonding(struct
> net_device *idev,
> +struct
> net_device *upper)
> +{
> + if (upper && IS_NETDEV_BONDING_MASTER(
Hi,
Yes , Matan and I need to work together and revisit this patch in light
of the split patch series and remove any references to RoCE v2...
Thanks for the feedback Jason and apologies for the oversight, we should
have worked this out internally before sending out V5
Regards
Som
> -Origin
On Thu, Jun 11, 2015 at 12:49:59AM -0400, Doug Ledford wrote:
> fact that the mlx4 driver and the ocrdma driver had their own gid
> management code, there were some distinct differences between the two.
> The gid at index 0 never matched up in my testing for example. One
> supported bonding, the
On Fri, 2015-06-05 at 15:47 +0100, Colin King wrote:
> From: Colin Ian King
>
> A reorganisation of the PD allocation and deallocation in commit
> 9ba1377daa ("RDMA/ocrdma: Move PD resource management to driver.")
> introduced a double free on pd, as detected by static analysis by
> smatch:
>
>
On Wed, 2015-06-10 at 12:13 +0300, Moni Shoua wrote:
> Registering an event handler is done for a device. This device may have
> one RoCE port (no SA cap) and one InfiniBand port (has SA cap).
> Therefore, warning from the event handler about a specific port that
> doesn't have SA cap is correct bu
On Tue, 2015-06-09 at 18:23 +0530, Hariprasad Shenai wrote:
> Hi,
>
> This patch series adds support for user mode bar2 mappings for T4 adapter
> and also adds support for bar2 qid densities exceeding page size.
>
> This patch series has been created against Doug's github tree 'for-4.1'
> branch
On Wed, 2015-06-10 at 21:57 -0600, Jason Gunthorpe wrote:
> On Wed, Jun 10, 2015 at 09:06:28PM -0400, Doug Ledford wrote:
>
> > People tend to push the "patches should be small, self contained,
> > incremental" ideal. In some cases, that gets carried to an extreme. In
> > this case, patch 1 intr
On Mon, Jun 08, 2015 at 05:12:06PM +0300, Matan Barak wrote:
> drivers/infiniband/core/core_priv.h | 26 ++
> drivers/infiniband/core/device.c | 77 +
I wouldn't mind seeing the core portion which consists of adding
the get_netdev be it's own little mini-series of three, adding
On Mon, Jun 08, 2015 at 05:12:15PM +0300, Matan Barak wrote:
> From: Somnath Kotur
>
> 1.Check and set port capability flags to indicate RoCEV2 support.
??? This series has nothing to with rocev2 now, what is this about?
> mutex_init(&dev->dev_lock);
> - dev->sgid_tbl = kzalloc(sizeof
On Wed, Jun 10, 2015 at 08:15:56PM -0400, Doug Ledford wrote:
> I'm not sure the complexity here is "latent RoCEv2" stuff versus simple
> over-design.
Well, for instance, the wrong RCU locking around
table->data_vec[ix].attr.ndev appears to exist to support find_gid
when called with GID_ATTR_FIND_
On Wed, Jun 10, 2015 at 09:06:28PM -0400, Doug Ledford wrote:
> People tend to push the "patches should be small, self contained,
> incremental" ideal. In some cases, that gets carried to an extreme. In
> this case, patch 1 introduces one side of the locking and patch 3 and 5
> introduce the oth
On Wed, 2015-06-10 at 23:17 +, Diego Crupnicoff wrote:
> Here Sean reacts to our RoCEv2 patches (same thread as the one I sent before
> with Jason's feedback).
> Sean is not even making technical statements to dismiss our patches. He has
> been rejecting all our previous revs of this set with
On Wed, 10 Jun 2015, Jerome Glisse wrote:
> [...]
>
> Like said, just ignore current code it is utterly broken in so many way
> when it comes to lifetime. I screw that part badly when reworking the
> patchset, i was focusing on other part.
>
> I fixed that in my tree, i am waiting for more rev
On Wed, 2015-06-10 at 12:49 -0600, Jason Gunthorpe wrote:
> On Wed, Jun 10, 2015 at 06:08:30PM +0300, Matan Barak wrote:
> > >It isn't really a cleanup because the whole gid table is new code and
> > >has latent elements for rocev2 - this is why it is so much bigger than
> > >it should be.
> >
> >
On Wed, 2015-06-10 at 09:00 -0600, Jason Gunthorpe wrote:
> On Wed, Jun 10, 2015 at 11:53:15AM +0300, Or Gerlitz wrote:
>
> > Jason, can you ack that this post addressed your comments?
>
> Well, I asked for a cleanup series, multiple times, and this is the
> closest things have got.
>
> It isn't
On Wed, 2015-06-10 at 11:45 +0300, Or Gerlitz wrote:
> On 6/10/2015 4:26 AM, Christoph Lameter wrote:
> >> >I have no problem with a bare metal interface exposing this. But
> >> >pretendin=
> >> >g that it's generic and that this is the one and only way that this could
> >> >b=
> >> >e implement
Here Sean reacts to our RoCEv2 patches (same thread as the one I sent before
with Jason's feedback).
Sean is not even making technical statements to dismiss our patches. He has
been rejecting all our previous revs of this set with loose FUD comments. In
this case he chose to count the lines of c
On Wed, Jun 10, 2015 at 11:19:03PM +0300, Matan Barak wrote:
> > Sure gid_type is gone, but I didn't say roceve2 specific, I said
> > latent elements. ie I'm assuming reasons for the scary locking are
> > because the ripped out rocev2 code needed it? And some of the
> > complexity that looks poin
On Wed, Jun 10, 2015 at 09:34:58PM +, Hefty, Sean wrote:
> I agree. I just wanted to make sure that there wasn't some feature
> regarding PRs, such as unpath, that a kernel client would lose
> (i.e. it is currently implemented) by changing how the PRs are
> retrieved. Basically nothing break
> Not directly. IPoIB treats it that way. I guess to "be safe".
>
> Officially one should register for UnPath/RePath traps. But no one has
> ever implemented that.
>
> To be clear I am agreeing with Hal that having some sort of "update
> signal" would be nice. But I don't think that must be d
>
> > > > This series does not attempt to optimize the kernel needing to
> > > > know that a PR has been updated. There are existing mechanisms for
> that.
> > >
> > > Does this exist in the kernel?
> >
> > At least some support, yes. For example client reregister marks all
> > IPoIB paths as in
> > > This series does not attempt to optimize the kernel needing to know
> > > that a PR has been updated. There are existing mechanisms for that.
> >
> > Does this exist in the kernel?
>
> At least some support, yes. For example client reregister marks all IPoIB
> paths as invalid.
Reregister
> On 6/10/2015 3:10 PM, Jason Gunthorpe wrote:
> > On Wed, Jun 10, 2015 at 01:47:36PM -0400, Hal Rosenstock wrote:
> >> On 6/9/2015 10:57 AM, kaike@intel.com wrote:
> >>> From: Kaike Wan
> >>>
> >>> This patch routes a SA pathrecord query to netlink first
> >>
> >> Should only unicast PRs be d
>
> > This series does not attempt to optimize the kernel needing to know
> > that a PR has been updated. There are existing mechanisms for that.
>
> Does this exist in the kernel?
At least some support, yes. For example client reregister marks all IPoIB
paths as invalid.
Ira
--
To unsubscr
> >>> +/* Local Service Reversible attribute */ struct
> >>> +rdma_nla_ls_reversible {
> >>> + __u32 reversible;
> >>> +};
> >>
> >> Isn't __u8 sufficient for reversible ?
> > Certainly enough. However, reversible is __u32 in struct
> ib_user_path_rec and int in struct ib_sa_path_rec.
>
On Wed, Jun 10, 2015 at 9:49 PM, Jason Gunthorpe
wrote:
> On Wed, Jun 10, 2015 at 06:08:30PM +0300, Matan Barak wrote:
>> >It isn't really a cleanup because the whole gid table is new code and
>> >has latent elements for rocev2 - this is why it is so much bigger than
>> >it should be.
>>
>> I disa
From: Ira Weiny
For devices which support OPA MADs
1) Use previously defined SMP support functions.
2) Pass correct base version to ib_create_send_mad when processing OPA MADs.
3) Process out_mad_key_index returned by agents for a response. This is
necessary because OPA SMP pac
On Wed, 2015-06-10 at 12:56 -0600, Jason Gunthorpe wrote:
> On Wed, Jun 10, 2015 at 02:37:26PM -0400, Doug Ledford wrote:
> > On Wed, 2015-06-10 at 06:30 +, Liran Liss wrote:
> > > > From: Ira Weiny
> > >
> > > Hi Ira,
> > >
> > > OPA cannot impersonate IB; OPA node and link types have to be
On 6/10/2015 2:31 PM, Wan, Kaike wrote:
>> From: Hal Rosenstock [mailto:h...@dev.mellanox.co.il]
>> Sent: Wednesday, June 10, 2015 1:47 PM
>>
>> On 6/9/2015 10:57 AM, kaike@intel.com wrote:
>>> From: Kaike Wan
>>>
>>> This patch adds netlink defines for SA client, local service group,
>>> loca
On 6/10/2015 3:10 PM, Jason Gunthorpe wrote:
> On Wed, Jun 10, 2015 at 01:47:36PM -0400, Hal Rosenstock wrote:
>> On 6/9/2015 10:57 AM, kaike@intel.com wrote:
>>> From: Kaike Wan
>>>
>>> This patch routes a SA pathrecord query to netlink first
>>
>> Should only unicast PRs be done in this mann
On 6/10/2015 1:04 PM, Hefty, Sean wrote:
>> Not in the patches themselves but in the general issue when a PR changes.
>>
>> Do you think this needs addressing or are things fine as they are now ?
>
> IMO, I think it needs addressing in terms of "can the proposed netlink
> architecture and design
On Wed, Jun 10, 2015 at 05:04:55PM +, Hefty, Sean wrote:
> > Not in the patches themselves but in the general issue when a PR changes.
> >
> > Do you think this needs addressing or are things fine as they are now ?
>
> IMO, I think it needs addressing in terms of "can the proposed
> netlink a
On Wed, Jun 10, 2015 at 01:47:36PM -0400, Hal Rosenstock wrote:
> On 6/9/2015 10:57 AM, kaike@intel.com wrote:
> > From: Kaike Wan
> >
> > This patch routes a SA pathrecord query to netlink first
>
> Should only unicast PRs be done in this manner or should API support
> enabling for unicast
On Wed, Jun 10, 2015 at 02:37:26PM -0400, Doug Ledford wrote:
> On Wed, 2015-06-10 at 06:30 +, Liran Liss wrote:
> > > From: Ira Weiny
> >
> > Hi Ira,
> >
> > OPA cannot impersonate IB; OPA node and link types have to be
> > designated as such. In terms of MAD processing flows, both
> > exp
On Wed, Jun 10, 2015 at 06:08:30PM +0300, Matan Barak wrote:
> >It isn't really a cleanup because the whole gid table is new code and
> >has latent elements for rocev2 - this is why it is so much bigger than
> >it should be.
>
> I disagree. Could you please point on anything that is RoCE V2 specif
> From: Hal Rosenstock [mailto:h...@dev.mellanox.co.il]
> Sent: Wednesday, June 10, 2015 1:47 PM
>
> On 6/9/2015 10:57 AM, kaike@intel.com wrote:
> > From: Kaike Wan
> >
> > This patch adds netlink defines for SA client, local service group,
> > local service operations, and related attribute
On Wed, 2015-06-10 at 06:30 +, Liran Liss wrote:
> > From: Ira Weiny
>
> Hi Ira,
>
> OPA cannot impersonate IB; OPA node and link types have to be designated as
> such.
> In terms of MAD processing flows, both explicit (as in the handle_opa_smi()
> call below) and implicit code paths (whic
> This series does not attempt to optimize the kernel needing to know that a
> PR
> has been updated. There are existing mechanisms for that.
Does this exist in the kernel?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.
On Wed, Jun 10, 2015 at 10:39:49AM -0400, Hal Rosenstock wrote:
> On 6/10/2015 10:22 AM, Wan, Kaike wrote:
> >
> >
> >> -Original Message-
> >> From: Hal Rosenstock [mailto:h...@dev.mellanox.co.il]
> >> Sent: Wednesday, June 10, 2015 9:37 AM
> >>
> >>>
> >>> A SA cache is undeniably criti
On Wed, Jun 10, 2015 at 06:30:58AM +, Liran Liss wrote:
> > From: Ira Weiny
>
> Hi Ira,
>
> OPA cannot impersonate IB; OPA node and link types have to be designated as
> such.
This was discussed at length and we agreed that the kernel would have explicit
capabilities communicated between t
On 6/9/2015 10:57 AM, kaike@intel.com wrote:
> From: Kaike Wan
>
> This patch adds netlink defines for SA client, local service group, local
> service operations, and related attributes.
>
> Signed-off-by: Kaike Wan
> Signed-off-by: John Fleck
> Signed-off-by: Ira Weiny
> Reviewed-by: Sea
On 6/9/2015 10:57 AM, kaike@intel.com wrote:
> From: Kaike Wan
>
> This patch routes a SA pathrecord query to netlink first
Should only unicast PRs be done in this manner or should API support
enabling for unicast and/or multicast ?
AFAIK kernel doesn't query multicast PRs now (queries MCMR
On 06/10/2015 06:35 AM, Hal Rosenstock wrote:
On 6/9/2015 9:52 PM, Bob Ciotti wrote:
We have an issue where lustre servers and clients cannot talk to each
other.
There are about 11,000 clients all trying to connect to a server that
just been rebooted
(nbp6-oss3 in this example)
pfe21 is a lus
> Not in the patches themselves but in the general issue when a PR changes.
>
> Do you think this needs addressing or are things fine as they are now ?
IMO, I think it needs addressing in terms of "can the proposed netlink
architecture and design accommodate this sort of request in the future?"
On 6/10/2015 11:21 AM, Hefty, Sean wrote:
>> While this appears to address the current upstream use model for ACM
>> with it's multicast overlay backend where PRs are static, it does not
>> appear to address PR changes.
>
> Although this ties into ibacm, from the viewpoint of the kernel, there's n
On 6/10/2015 11:49 AM, Wan, Kaike wrote:
>>> A SA cache is undeniably critical for fabric scalability and
>>> performance.
>>> In user space, the ibacm application provides a good example of
>>> pathrecord cache for address and route resolution. With the recent
>>> implementati
Use kernel.h macro definition.
Thanks to Julia Lawall for Coccinelle scripting support.
Signed-off-by: Fabian Frederick
---
drivers/infiniband/hw/mthca/mthca_profile.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_profile.c
b/driv
> > > Registering an event handler is done for a device. This device may
> > > have one RoCE port (no SA cap) and one InfiniBand port (has SA cap).
> > > Therefore, warning from the event handler about a specific port that
> > > doesn't have SA cap is correct but pollutes the kernel log without a
>
On Wed, Jun 10, 2015 at 04:06:18PM +0300, Erez Shitrit wrote:
> > + if (unlikely(ipoib_dma_map_tx(priv->ca, tx_req))) {
> > + ++dev->stats.tx_errors;
> > + dev_kfree_skb_any(skb);
> > + return;
> > + }
>
On Wed, 2015-06-10 at 11:43 +0300, Moni Shoua wrote:
> The Subnet Administrator (SA) is not a component of the RoCE spec.
> Therefore, it should not be a capability of a RoCE port.
>
> Signed-off-by: Moni Shoua
> ---
> include/rdma/ib_verbs.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --gi
> There are multiple problems with libfrabric related to the use cases in my
> area. Most of all the lack of multicast support. Then there is the build
> up of software bloat on top. The interest here is in low latency
> operations. Redenzvous and other new features are really not wanted if
> they
> RDMA_CM_EVENT_UNREACHABLE is indicated when there are timeouts in
> underlying CM protocol exchange. I suspect that the server is really
> busy and doesn't respond to the low level CM MADs in a timely manner.
> RDMA CM (and other kernel ULPs like IPoIB and SRP use hard coded local
> and remote re
> > A SA cache is undeniably critical for fabric scalability and
> > performance.
> > In user space, the ibacm application provides a good example of
> > pathrecord cache for address and route resolution. With the recent
> > implementation of the provider architecture, ibacm of
On Tue, Jun 09, 2015 at 08:33:12PM -0700, Mark Hairgrove wrote:
>
>
> On Tue, 9 Jun 2015, Jerome Glisse wrote:
>
> > On Mon, Jun 08, 2015 at 06:54:29PM -0700, Mark Hairgrove wrote:
> > > Can you clarify how that's different from mmu_notifiers? Those are also
> > > embedded into a driver-owned st
> > Registering an event handler is done for a device. This device may have
> > one RoCE port (no SA cap) and one InfiniBand port (has SA cap).
> > Therefore, warning from the event handler about a specific port that
> > doesn't have SA cap is correct but pollutes the kernel log without a
> > need.
On 6/10/2015 6:00 PM, Jason Gunthorpe wrote:
On Wed, Jun 10, 2015 at 11:53:15AM +0300, Or Gerlitz wrote:
Jason, can you ack that this post addressed your comments?
Well, I asked for a cleanup series, multiple times, and this is the
closest things have got.
It isn't really a cleanup because
> While this appears to address the current upstream use model for ACM
> with it's multicast overlay backend where PRs are static, it does not
> appear to address PR changes.
Although this ties into ibacm, from the viewpoint of the kernel, there's no
requirement on the user space implementation.
On 6/10/2015 6:09 PM, Hefty, Sean wrote:
Sean, this change is needed b/c two drivers have (mlx4 and ocrda) and
more two to come soon (mlx5 and soft-Roce) would have the very same
logic of constructing the port GID table according to netdev events and
such, no point in repeating this logic/code
On 6/10/2015 11:07 AM, Wan, Kaike wrote:
>
>
>> -Original Message-
>> From: Hal Rosenstock [mailto:h...@dev.mellanox.co.il]
>> Sent: Wednesday, June 10, 2015 10:40 AM
>>>
>>>
-Original Message-
From: Hal Rosenstock [mailto:h...@dev.mellanox.co.il]
Sent: Wednesday, J
> Sean, this change is needed b/c two drivers have (mlx4 and ocrda) and
> more two to come soon (mlx5 and soft-Roce) would have the very same
> logic of constructing the port GID table according to netdev events and
> such, no point in repeating this logic/code over and over.
>
> Matan explained w
> -Original Message-
> From: Hal Rosenstock [mailto:h...@dev.mellanox.co.il]
> Sent: Wednesday, June 10, 2015 10:40 AM
> >
> >
> >> -Original Message-
> >> From: Hal Rosenstock [mailto:h...@dev.mellanox.co.il]
> >> Sent: Wednesday, June 10, 2015 9:37 AM
> >>
> >>>
> >>> A SA cache
On Wed, Jun 10, 2015 at 11:53:15AM +0300, Or Gerlitz wrote:
> Jason, can you ack that this post addressed your comments?
Well, I asked for a cleanup series, multiple times, and this is the
closest things have got.
It isn't really a cleanup because the whole gid table is new code and
has latent e
On 6/10/2015 10:22 AM, Wan, Kaike wrote:
>
>
>> -Original Message-
>> From: Hal Rosenstock [mailto:h...@dev.mellanox.co.il]
>> Sent: Wednesday, June 10, 2015 9:37 AM
>>
>>>
>>> A SA cache is undeniably critical for fabric scalability and performance.
>>> In user space, the ibacm applicati
> -Original Message-
> From: Hal Rosenstock [mailto:h...@dev.mellanox.co.il]
> Sent: Wednesday, June 10, 2015 9:37 AM
>
> >
> > A SA cache is undeniably critical for fabric scalability and performance.
> > In user space, the ibacm application provides a good example of
> > pathrecord cac
On 6/9/2015 10:57 AM, kaike@intel.com wrote:
> From: Kaike Wan
>
> A SA cache is undeniably critical for fabric scalability and performance.
> In user space, the ibacm application provides a good example of pathrecord
> cache for address and route resolution. With the recent implementation of
On 6/9/2015 9:52 PM, Bob Ciotti wrote:
> We have an issue where lustre servers and clients cannot talk to each
> other.
> There are about 11,000 clients all trying to connect to a server that
> just been rebooted
> (nbp6-oss3 in this example)
>
> pfe21 is a lustre client thats trying to remount th
On Mon, May 11, 2015 at 1:04 PM, Yuval Shaia wrote:
> By default, IPoIB-CM driver uses 64k MTU. Larger MTU gives better performance.
> This MTU plus overhead puts the memory allocation for IP based packets at 32
> 4k pages (order 5), which have to be contiguous.
> When the system memory under pres
Hi, Moni
On 06/10/2015 11:13 AM, Moni Shoua wrote:
> Registering an event handler is done for a device. This device may have
> one RoCE port (no SA cap) and one InfiniBand port (has SA cap).
> Therefore, warning from the event handler about a specific port that
> doesn't have SA cap is correct but
On Mon, May 11, 2015 at 1:04 PM, Yuval Shaia wrote:
> By default, IPoIB-CM driver uses 64k MTU. Larger MTU gives better performance.
> This MTU plus overhead puts the memory allocation for IP based packets at 32
> 4k pages (order 5), which have to be contiguous.
> When the system memory under pres
Registering an event handler is done for a device. This device may have
one RoCE port (no SA cap) and one InfiniBand port (has SA cap).
Therefore, warning from the event handler about a specific port that
doesn't have SA cap is correct but pollutes the kernel log without a
need.
Signed-off-by: Mon
On 6/9/2015 10:27 AM, Matan Barak wrote:
On 6/9/2015 12:37 AM, Hefty, Sean wrote:
Previously, every vendor implemented its net device notifiers in its
own
driver. This introduces a huge code duplication as figuring
28 files changed, 2253 insertions(+), 860 deletions(-)
How does adding
On 6/10/2015 4:26 AM, Christoph Lameter wrote:
>I have no problem with a bare metal interface exposing this. But pretendin=
>g that it's generic and that this is the one and only way that this could b=
>e implemented doesn't make it so.
This is a way it was implemented and its usable. Shooting
The Subnet Administrator (SA) is not a component of the RoCE spec.
Therefore, it should not be a capability of a RoCE port.
Signed-off-by: Moni Shoua
---
include/rdma/ib_verbs.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 7d78794..77
On 6/10/2015 8:35 AM, Moni Shoua wrote:
The Subnet Administrator (SA) is not a component of the RoCE spec.
Therefore, it should not be a capability of a RoCE port.
Change-Id: Iadfaa56bdc9f6e28f46d009064c2d15969293cf7
Please remove the internal Gerrit IDs we use prior to sending patches out
S
76 matches
Mail list logo
