On Tue, Jan 17, 2012 at 10:21:28AM -0600, Steve Wise wrote:
> On 01/17/2012 09:59 AM, Or Gerlitz wrote:
> >On 1/17/2012 5:08 PM, Steve Wise wrote:
> >>I think this series should add some new send flags for HW that
> >>does checksum offload [...] also, on ingress, most hardware can
> >>do INET check
On Wed, Apr 24, 2013 at 04:58:43PM +0300, Or Gerlitz wrote:
> Hi Roland, all
>
> The first five patches in the series are mlx4 DMFS (Device Managed Flow
> Steering) pre-patches needed for flow steering access from the mlx4 IB driver.
>
> net/mlx4_core: Move DMFS HW structs to common header fil
Christoph Lameter writes:
>
> We have an app here that runs fine with OFED. But if I try to use the
> kernel IB subsystem in 3.2 it complains about packets being looped back to
> the application.
>
> That seems to be controlled by IB_DEVICE_BLOCK_MULTICAST_LOOPBACK and
> IB_QP_CREATE_BLOCK_MULTI
It appears the upstream libmlx4/libibverbs currently do not support
multicast IBoE traffic. For example:
$ mckey -m 239.1.1.1 -b 10.0.202.3
mckey: starting server
mckey: joining
mckey: joined dgid: ff0e:::ef01:101 mlid 0x0 sl 0
mckey: failure creating address handle
test complete
return statu
On Wed, Nov 23, 2011 at 11:17:02PM +0200, Or Gerlitz wrote:
> Roland Dreier wrote:
> > looks like the libmlx4 patches I applied from you are missing multicast AH
> > support?
>
> Yes, when I reworked the patches for submission I went from easier
> (RC) to harder (ucast UD + Vlans) and eventually
On Wed, Jan 11, 2012 at 09:49:25PM +0200, Or Gerlitz wrote:
> Shawn Bohrer wrote:
> > Is there any estimate on when we might see something like this upstream?
>
> Could you elaborate a little on your use case for multicast IBoE
> traffic? e.g how the setup looks like and how
Hi Or,
On Thu, Jan 12, 2012 at 11:01:58AM -0600, Shawn Bohrer wrote:
> On Wed, Jan 11, 2012 at 09:49:25PM +0200, Or Gerlitz wrote:
> > Shawn Bohrer wrote:
> > > Is there any estimate on when we might see something like this upstream?
> >
> > Could you elaborate
Add multicast support for IBoE to the address handle creation flow.
Derived from work by Eli Cohen
Signed-off-by: Shawn Bohrer
---
src/verbs.c | 38 +++---
1 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/src/verbs.c b/src/verbs.c
index 199d107
Sorry, probably should have mentioned this is a patch for libmlx4.
On Wed, Jan 25, 2012 at 04:56:48PM -0600, Shawn Bohrer wrote:
> Add multicast support for IBoE to the address handle creation flow.
> Derived from work by Eli Cohen
>
> Signed-off-by: Shawn Bohrer
> ---
>
Add multicast support for IBoE to the address handle creation flow.
Derived from work by Eli Cohen
Signed-off-by: Shawn Bohrer
---
src/verbs.c | 38 +++---
1 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/src/verbs.c b/src/verbs.c
index 199d107
I'm running into some issues using IBoE on a vlan with an upstream
kernel and libraries (works fine with OFED). I'm mostly curious if
I'm simply running into a feature not yet implemented upstream, or if
I've found a bug. I'm currently testing this on Fedora 16 with:
3.1.9 kernel
librdmacm-1.0.1
On Fri, Feb 24, 2012 at 10:32:30AM -0600, Shawn Bohrer wrote:
> Add multicast support for IBoE to the address handle creation flow.
> Derived from work by Eli Cohen
>
> Signed-off-by: Shawn Bohrer
> ---
> src/verbs.c | 38 +++---
>
On Mon, Mar 26, 2012 at 12:17 PM, Roland Dreier wrote:
> libmlx4 is a userspace driver for Mellanox ConnectX InfiniBand/IBoE
> HCAs. It si a plug-in module for libibverbs that allows programs to
> use Mellanox hardware directly from userspace.
>
> A new stable release is available from
>
> htt
On Mon, Mar 26, 2012 at 5:09 PM, Roland Dreier wrote:
>> + ah->av.dlid = htons(0xc);
>
> Presumably this should be 0xc000 not 0xc?
Yes, I apparently fat fingered this. Do you need me to resend or will
you just fix that up?
Thanks,
Shawn
--
To unsubscribe from this list: se
On Wed, Mar 28, 2012 at 4:45 PM, Or Gerlitz wrote:
> On Wed, Mar 28, 2012 at 8:42 PM, Roland Dreier wrote:
>> Update maintainer now that I'm a DD
>
> So what is DD?
Looking at the patch it appears it means Debian Developer.
--
Shawn
--
To unsubscribe from this list: send the line "unsubscr
> wrote:
> > > > On Mon, Jul 01, 2013 at 09:54:56AM -0500, Shawn Bohrer wrote:
> > > >> I've managed to hit a deadlock at boot a couple times while testing
> > > >> the 3.10 rc kernels. It seems to always happen when my network
> > > &g
On Wed, Jul 03, 2013 at 08:26:11PM +0300, Or Gerlitz wrote:
> On 03/07/2013 20:22, Shawn Bohrer wrote:
> >On Wed, Jul 03, 2013 at 07:33:07AM +0200, Hannes Frederic Sowa wrote:
> >>On Wed, Jul 03, 2013 at 07:11:52AM +0200, Hannes Frederic Sowa wrote:
> >>>On Tue, Ju
On Mon, Jul 15, 2013 at 09:38:19AM -0500, Shawn Bohrer wrote:
> On Wed, Jul 03, 2013 at 08:26:11PM +0300, Or Gerlitz wrote:
> > On 03/07/2013 20:22, Shawn Bohrer wrote:
> > >On Wed, Jul 03, 2013 at 07:33:07AM +0200, Hannes Frederic Sowa wrote:
> > >>On Wed, Jul 03, 20
On Wed, Jul 03, 2013 at 08:42:12PM +0300, Or Gerlitz wrote:
> Hi Roland, all
>
> V3 addresses the comments made by Sean. There are still some
> concerns/questions posed
> by Roland on the uverbs extensions element of the series. I have posted
> replies for
> them, but so far no further comments
On Thu, Sep 05, 2013 at 10:14:51AM -0500, Steve Wise wrote:
> On 9/5/2013 5:02 AM, Bart Van Assche wrote:
> >On 07/30/13 14:54, Steve Wise wrote:
> >>On 7/29/2013 6:02 PM, Shawn Bohrer wrote:
> >>>On Mon, Jul 15, 2013 at 09:38:19AM -0500, Shawn Bohrer wrote:
>
On Thu, Sep 05, 2013 at 12:02:12PM +0200, Bart Van Assche wrote:
> On 07/30/13 14:54, Steve Wise wrote:
> >On 7/29/2013 6:02 PM, Shawn Bohrer wrote:
> >>On Mon, Jul 15, 2013 at 09:38:19AM -0500, Shawn Bohrer wrote:
> >>>On Wed, Jul 03, 2013 at 08:26:11PM +0300, Or
On Thu, Sep 05, 2013 at 10:14:51AM -0500, Steve Wise wrote:
> Roland, what do you think?
>
> As I've said, I think we should go ahead with using the rtnl lock in
> the core. Is there a complete patch available for review? looks
> like the original was a partial fix.
I guess I should realize tha
From: Shawn Bohrer
In debugging an application that receives -ENOMEM from ib_reg_mr() I
found that ib_umem_get() can fail because the pinned_vm count has
wrapped causing it to always be larger than the lock limit even with
RLIMIT_MEMLOCK set to RLIM_INFINITY.
The wrapping of pinned_vm occurs
On Tue, Aug 12, 2014 at 11:27:35AM -0500, Shawn Bohrer wrote:
> From: Shawn Bohrer
>
> In debugging an application that receives -ENOMEM from ib_reg_mr() I
> found that ib_umem_get() can fail because the pinned_vm count has
> wrapped causing it to always be larger than the lock
e to be destroyed,
> and the file handle is waiting for the mm to be destroyed.
>
> The proper solution is to keep a reference to the task_pid (using
> get_task_pid), and use this pid to get the task_struct and from it
> the mm_struct during the destruction flow.
I'll put to
From: Shawn Bohrer
In debugging an application that receives -ENOMEM from ib_reg_mr() I
found that ib_umem_get() can fail because the pinned_vm count has
wrapped causing it to always be larger than the lock limit even with
RLIMIT_MEMLOCK set to RLIM_INFINITY.
The wrapping of pinned_vm occurs
On Thu, Aug 28, 2014 at 02:48:19PM +0300, Haggai Eran wrote:
> On 26/08/2014 00:07, Shawn Bohrer wrote:
> >>>> The following patch fixes the issue by storing the mm_struct of the
> >> >
> >> > You are doing more than just storing the mm_struct - you ar
From: Shawn Bohrer
In debugging an application that receives -ENOMEM from ib_reg_mr() I
found that ib_umem_get() can fail because the pinned_vm count has
wrapped causing it to always be larger than the lock limit even with
RLIMIT_MEMLOCK set to RLIM_INFINITY.
The wrapping of pinned_vm occurs
On Wed, Sep 03, 2014 at 12:13:57PM -0500, Shawn Bohrer wrote:
> From: Shawn Bohrer
>
> In debugging an application that receives -ENOMEM from ib_reg_mr() I
> found that ib_umem_get() can fail because the pinned_vm count has
> wrapped causing it to always be larger than the lock
29 matches
Mail list logo
