On Tue, Apr 07, 2015 at 03:16:30PM -0500, Steve Wise wrote:
>
>
> > -Original Message-
> > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> > Sent: Tuesday, April 07, 2015 3:13 PM
> > To: Michael Wang
> > Cc: Roland Dreier; Sean Hefty; linux-rdma@vger.kernel.org;
> > linu
On Fri, Apr 03, 2015 at 05:47:49PM -0600, Hefty, Sean wrote:
> > @@ -236,6 +252,24 @@ enum smi_action smi_handle_dr_smp_recv(struct ib_smp
> > *smp, u8 node_type,
> > smp->dr_slid == IB_LID_PERMISSIVE);
> > }
> >
> > +/*
> > + * Adjust information for a receive
> > Didn't an earlier patch make is possible to read the mad_size directly
> from the device?
> >
>
> Not exactly, that patch specified the "max_mad_size" the device supported.
>
> OPA devices support IB MADs. If the IB Base Version is specified on an
> OPA
> device the IB MAD size is to be used
On Fri, Apr 03, 2015 at 05:33:55PM -0600, Hefty, Sean wrote:
> > /* Registration table sizes */
> > #define MAX_MGMT_CLASS 80
> > -#define MAX_MGMT_VERSION 8
> > +#define MAX_MGMT_VERSION 0x83
>
> It's unfortunate that this results in a big jump in used versions.
> Mad_priv.h d
On Fri, Apr 03, 2015 at 05:40:22PM -0600, Hefty, Sean wrote:
> > @@ -937,20 +937,31 @@ struct ib_mad_send_buf * ib_create_send_mad(struct
> > ib_mad_agent *mad_agent,
> > struct ib_mad_send_wr_private *mad_send_wr;
> > int pad, message_size, ret, size;
> > void *buf;
> > + size_t mad_
On Tue, Apr 07, 2015 at 11:19:20AM -0600, Jason Gunthorpe wrote:
> On Tue, Apr 07, 2015 at 05:15:07PM +, Hefty, Sean wrote:
>
> > IMO, a MAD should be self-identifying.
A "MAD" is self-identifying (contains versions and classes).
IBoE CM MADs are a sub-set of the IB MADs. As are the PMA MAD
On 4/8/2015 4:10 PM, Jason Gunthorpe wrote:
On Wed, Apr 08, 2015 at 02:29:46PM -0400, Doug Ledford wrote:
...
rdma_port_get_read_sge(dev, port)
{
if (rdma_transport_is_iwarp)
return 1;
return dev->port[port]->max_sge;
}
Hum, that is nice, but it doesn't quite
On Wed, Apr 08, 2015 at 02:29:46PM -0400, Doug Ledford wrote:
> To straighten all this out, lets break management out into the two
> distinct types:
>
> rdma_port_ib_fabric_mgmt() <- fabric specific management tasks: MAD, SM,
> multicast. The proper test for this with my bitmap above is a simple
In a call to ib_umem_get(), if address is 0x0 and size is
already page aligned, check added in commit 8494057ab5e4
("IB/uverbs: Prevent integer overflow in ib_umem_get address
arithmetic") will refuse to register a memory region that
could otherwise be valid (provided vm.mmap_min_addr sysctl
and mm
[Re-sent patch set with correct Cc: ]
Hi,
Please find one patch to prevent a possible issue partially
addressed by commit 8494057ab5e4 ("IB/uverbs: Prevent integer
overflow in ib_umem_get address arithmetic") (see discussions
in [1]) and another one to add back the possibility of registering
memo
If ib_umem_get() is called with a size equal to 0 and an
non-page aligned address, one page will be pinned and a
0-sized umem will be returned to the caller.
This should not be allowed: it's not expected for a memory
region to have a size equal to 0.
This patch adds a check to explicitly refuse t
On Wed, Apr 08, 2015 at 06:41:22PM +, Hefty, Sean wrote:
> I too would like to see this as the end result, but I think it's
> possible to stage the changes by having the static inline calls
> being added convert to using these sort of attributes.
I agree as well, this patch set is already so
> I'm concerned about the performance implications of this. The size of
> this patchset already points out just how many places in the code we
> have to check for various aspects of the device transport in order to do
> the right thing. Without going through the entire list to see how many
> are
On Tue, 2015-04-07 at 14:42 +0200, Michael Wang wrote:
> Add new callback query_transport() and implement for each HW.
My response here is going to be a long email, but that's because it's
easier to respond to the various patches all in one response in order to
preserve context. So, while I'm res
All,
I am trying to find out if RDMA Multicasting is supported on RoCE in Linux.
If so, is it supported above the verbs interface?
Allen Andrews
Emulex
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo in
> On 04/07/2015 11:36 PM, Hefty, Sean wrote:
> >> diff --git a/drivers/infiniband/core/cma.c
> b/drivers/infiniband/core/cma.c
> >> index d8a8ea7..c23f483 100644
> >> --- a/drivers/infiniband/core/cma.c
> >> +++ b/drivers/infiniband/core/cma.c
> >> @@ -435,10 +435,10 @@ static int cma_resolve_ib_de
On Tue, Apr 07, 2015 at 11:53:00AM -0600, Hefty, Sean wrote:
> > > Rather than calling device->process_mad() directly, would it be better
> > to call a common function? So we can avoid adding:
> > >
> > > > + struct ib_mad *in_mad = (struct ib_mad *)in;
> > > > + struct ib_mad *out_mad
On 04/08/2015 05:51 PM, Jason Gunthorpe wrote:
> On Wed, Apr 08, 2015 at 02:41:18PM +0200, Michael Wang wrote:
>
>> I think no one can have the access to all these hardware, so we can
>> only depends on those who accidentally have one to help the testing,
>> but it's still far from that stage..
>
On Mon, Apr 06, 2015 at 04:43:01PM -0600, Hefty, Sean wrote:
> > I understand your point and I originally called this "attributes" but it
> > was
> > suggested to call it cached_dev_attrs.
> >
> > https://www.mail-archive.com/linux-rdma%40vger.kernel.org/msg22486.html
> >
> > I can change it back
On Wed, Apr 08, 2015 at 02:41:18PM +0200, Michael Wang wrote:
> I think no one can have the access to all these hardware, so we can
> only depends on those who accidentally have one to help the testing,
> but it's still far from that stage..
I have seen other patches in this style use the compil
On Fri, Apr 03, 2015 at 05:08:53PM -0600, Hefty, Sean wrote:
> > Define jumbo_mad and jumbo_rmpp_mad.
>
> I would just use 'opa_mad' in place of 'jumbo_mad'. Jumbo sounds like a
> marketing term or elephant name.
Done in v5.
>
> > Jumbo MAD structures are 2K versions of ib_mad and ib_rmpp_ma
In a call to ib_umem_get(), if address is 0x0 and size is
already page aligned, check added in commit 8494057ab5e4
("IB/uverbs: Prevent integer overflow in ib_umem_get address
arithmetic") will refuse to register a memory region that
could otherwise be valid (provided vm.mmap_min_addr sysctl
and mm
If ib_umem_get() is called with a size equal to 0 and an
non-page aligned address, one page will be pinned and a
0-sized umem will be returned to the caller.
This should not be allowed: it's not expected for a memory
region to have a size equal to 0.
This patch adds a check to explicitly refuse t
Hi,
Please find one patch to prevent a possible issue partially
addressed by commit 8494057ab5e4 ("IB/uverbs: Prevent integer
overflow in ib_umem_get address arithmetic") (see discussions
in [1]) and another one to add back the possibility of registering
memory mapped at 0 (which is probably not s
On Sun, Apr 5, 2015 at 5:51 PM, Roland Dreier wrote:
> On Sat, Apr 4, 2015 at 10:15 PM, Or Gerlitz wrote:
>> Indeed. No maintainer voice makes it kind of impossible for
>> discussions to converge. What happens over the last years is that when
>> there's no easy consensus on matter Y, everyone sto
Hi,
Le mercredi 08 avril 2015 à 14:19 +0200, Yann Droneaud a écrit :
> Le jeudi 02 avril 2015 à 16:34 +, Shachar Raindel a écrit :
> > > -Original Message-
> > > From: Yann Droneaud [mailto:ydrone...@opteya.com]
> > > Sent: Thursday, April 02, 2015 6:16 PM
> > > Le jeudi 02 avril 2015
On 04/08/2015 01:38 PM, Tom Talpey wrote:
> On 4/7/2015 8:25 AM, Michael Wang wrote:
>> Mapping List:
>> node-typelink-layerold-transportnew-transport
>> nesRNICETHIWARPIWARP
>> amso1100RNICETHIWARPIWARP
>> cxgb3
Hi,
Le jeudi 02 avril 2015 à 16:34 +, Shachar Raindel a écrit :
> > -Original Message-
> > From: Yann Droneaud [mailto:ydrone...@opteya.com]
> > Sent: Thursday, April 02, 2015 6:16 PM
> > Le jeudi 02 avril 2015 à 10:52 +, Shachar Raindel a écrit :
> > > > -Original Message-
On 4/7/2015 8:25 AM, Michael Wang wrote:
Mapping List:
node-type link-layer old-transport new-transport
nes RNICETH IWARP IWARP
amso1100RNICETH IWARP IWARP
cxgb3 RNIC
Hi, Sean
Thanks for the review :-) cma is the most tough part during
reform, I really need some guide in here.
On 04/07/2015 11:36 PM, Hefty, Sean wrote:
>> diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
>> index d8a8ea7..c23f483 100644
>> --- a/drivers/infiniband/cor
On 04/07/2015 07:42 PM, Jason Gunthorpe wrote:
[snip]
>>> @@ -992,8 +992,8 @@ static struct svc_xprt *svc_rdma_accept(struct svc_xprt
>>> *xprt)
>>> dma_mr_acc = IB_ACCESS_LOCAL_WRITE;
>>> } else
>>> need_dma_mr = 0;
>>> - break;
>>> -
On Wed, Apr 8, 2015 at 2:30 AM, Hefty, Sean wrote:
>> In order to manage multiple types, vlans and MACs per GID, we
>> need to store them along the GID itself. We store the net device
>> as well, as sometimes GIDs should be handled according to the
>> net device they came from. Since populating th
On 04/07/2015 11:25 PM, Hefty, Sean wrote:
>> +static inline int rdma_transport_ib(struct ib_device *device, u8
>> port_num)
>> +{
>> +return device->query_transport(device, port_num)
>> +== RDMA_TRANSPORT_IB;
>> +}
>> +
>> +static inline int rdma_transport_iboe(struct ib_d
On 04/07/2015 11:11 PM, Steve Wise wrote:
[snip]
>> @@ -1006,17 +997,14 @@ static void cma_leave_mc_groups(struct
>> rdma_id_private *id_priv)
>> mc = container_of(id_priv->mc_list.next,
>>struct cma_multicast, list);
>> list_del(&mc->list
On 04/07/2015 08:49 PM, Hefty, Sean wrote:
[snip]
>> @@ -515,8 +515,10 @@ ssize_t ib_uverbs_query_port(struct ib_uverbs_file
>> *file,
>> resp.active_width= attr.active_width;
>> resp.active_speed= attr.active_speed;
>> resp.phys_state = attr.phys_state;
>> -resp.l
Hi, Steve
Thanks for the comment :-)
On 04/07/2015 10:16 PM, Steve Wise wrote:
[snip]
>>>
>>> - force_grh = rdma_port_get_link_layer(device, port_num) ==
>>> IB_LINK_LAYER_ETHERNET;
>>> + force_grh = !rdma_transport_ib(device, port_num);
>>
>> Maybe these tests should be called cap_mandatory
On 04/07/2015 08:40 PM, Hefty, Sean wrote:
[snip]
>> @@ -200,11 +200,9 @@ int ib_init_ah_from_wc(struct ib_device *device, u8
>> port_num, struct ib_wc *wc,
>> u32 flow_class;
>> u16 gid_index;
>> int ret;
>> -int is_eth = (rdma_port_get_link_layer(device, port_num) ==
>> -
On 04/07/2015 07:26 PM, Jason Gunthorpe wrote:
> On Tue, Apr 07, 2015 at 02:30:22PM +0200, Michael Wang wrote:
>
>> -if (rdma_node_get_transport(device->node_type) != RDMA_TRANSPORT_IB)
>> -return;
>> -
>> if (device->node_type == RDMA_NODE_IB_SWITCH) {
>> start =
38 matches
Mail list logo
