diff mbox series

[for-rc] IB/hfi1: Allow larger MTU without AIP

Message ID 1644348309-174874-1-git-send-email-mike.marciniszyn@cornelisnetworks.com (mailing list archive)
State Accepted
Delegated to: Jason Gunthorpe
Headers show
Series [for-rc] IB/hfi1: Allow larger MTU without AIP | expand

Commit Message

Marciniszyn, Mike Feb. 8, 2022, 7:25 p.m. UTC
From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>

The AIP code signals the phys_mtu in the following query_port()
fragment:

	props->phys_mtu = HFI1_CAP_IS_KSET(AIP) ? hfi1_max_mtu :
				ib_mtu_enum_to_int(props->max_mtu);

Using the largest MTU possible should not depend on AIP.

Fix by unconditionally using the hfi1_max_mtu value.

Reviewed-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
---
 drivers/infiniband/hw/hfi1/verbs.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Comments

Dennis Dalessandro March 1, 2022, 4:49 p.m. UTC | #1
On 2/8/22 2:25 PM, mike.marciniszyn@cornelisnetworks.com wrote:
> From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
> 
> The AIP code signals the phys_mtu in the following query_port()
> fragment:
> 
> 	props->phys_mtu = HFI1_CAP_IS_KSET(AIP) ? hfi1_max_mtu :
> 				ib_mtu_enum_to_int(props->max_mtu);
> 
> Using the largest MTU possible should not depend on AIP.
> 
> Fix by unconditionally using the hfi1_max_mtu value.
> 
> Reviewed-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
> ---
>  drivers/infiniband/hw/hfi1/verbs.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/hfi1/verbs.c b/drivers/infiniband/hw/hfi1/verbs.c
> index dc9211f..99d0743 100644
> --- a/drivers/infiniband/hw/hfi1/verbs.c
> +++ b/drivers/infiniband/hw/hfi1/verbs.c
> @@ -1397,8 +1397,7 @@ static int query_port(struct rvt_dev_info *rdi, u32 port_num,
>  				      4096 : hfi1_max_mtu), IB_MTU_4096);
>  	props->active_mtu = !valid_ib_mtu(ppd->ibmtu) ? props->max_mtu :
>  		mtu_to_enum(ppd->ibmtu, IB_MTU_4096);
> -	props->phys_mtu = HFI1_CAP_IS_KSET(AIP) ? hfi1_max_mtu :
> -				ib_mtu_enum_to_int(props->max_mtu);
> +	props->phys_mtu = hfi1_max_mtu;
>  
>  	return 0;
>  }

Fixes: 6d72344cf6c4 ("IB/ipoib: Increase ipoib Datagram mode MTU's upper limit")

Can this just get queued up for-next or should I resubmit with the fixes line above?

-Denny
Jason Gunthorpe March 1, 2022, 4:59 p.m. UTC | #2
On Tue, Mar 01, 2022 at 11:49:09AM -0500, Dennis Dalessandro wrote:
> On 2/8/22 2:25 PM, mike.marciniszyn@cornelisnetworks.com wrote:
> > From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
> > 
> > The AIP code signals the phys_mtu in the following query_port()
> > fragment:
> > 
> > 	props->phys_mtu = HFI1_CAP_IS_KSET(AIP) ? hfi1_max_mtu :
> > 				ib_mtu_enum_to_int(props->max_mtu);
> > 
> > Using the largest MTU possible should not depend on AIP.
> > 
> > Fix by unconditionally using the hfi1_max_mtu value.
> > 
> > Reviewed-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
> > Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
> >  drivers/infiniband/hw/hfi1/verbs.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/infiniband/hw/hfi1/verbs.c b/drivers/infiniband/hw/hfi1/verbs.c
> > index dc9211f..99d0743 100644
> > +++ b/drivers/infiniband/hw/hfi1/verbs.c
> > @@ -1397,8 +1397,7 @@ static int query_port(struct rvt_dev_info *rdi, u32 port_num,
> >  				      4096 : hfi1_max_mtu), IB_MTU_4096);
> >  	props->active_mtu = !valid_ib_mtu(ppd->ibmtu) ? props->max_mtu :
> >  		mtu_to_enum(ppd->ibmtu, IB_MTU_4096);
> > -	props->phys_mtu = HFI1_CAP_IS_KSET(AIP) ? hfi1_max_mtu :
> > -				ib_mtu_enum_to_int(props->max_mtu);
> > +	props->phys_mtu = hfi1_max_mtu;
> >  
> >  	return 0;
> >  }
> 
> Fixes: 6d72344cf6c4 ("IB/ipoib: Increase ipoib Datagram mode MTU's upper limit")
> 
> Can this just get queued up for-next or should I resubmit with the fixes line above?

Is it OK without the prior patch in the series?

Jason
Dennis Dalessandro March 1, 2022, 5:06 p.m. UTC | #3
On 3/1/22 11:59 AM, Jason Gunthorpe wrote:
> On Tue, Mar 01, 2022 at 11:49:09AM -0500, Dennis Dalessandro wrote:
>> On 2/8/22 2:25 PM, mike.marciniszyn@cornelisnetworks.com wrote:
>>> From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
>>>
>>> The AIP code signals the phys_mtu in the following query_port()
>>> fragment:
>>>
>>> 	props->phys_mtu = HFI1_CAP_IS_KSET(AIP) ? hfi1_max_mtu :
>>> 				ib_mtu_enum_to_int(props->max_mtu);
>>>
>>> Using the largest MTU possible should not depend on AIP.
>>>
>>> Fix by unconditionally using the hfi1_max_mtu value.
>>>
>>> Reviewed-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
>>> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
>>>  drivers/infiniband/hw/hfi1/verbs.c | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/infiniband/hw/hfi1/verbs.c b/drivers/infiniband/hw/hfi1/verbs.c
>>> index dc9211f..99d0743 100644
>>> +++ b/drivers/infiniband/hw/hfi1/verbs.c
>>> @@ -1397,8 +1397,7 @@ static int query_port(struct rvt_dev_info *rdi, u32 port_num,
>>>  				      4096 : hfi1_max_mtu), IB_MTU_4096);
>>>  	props->active_mtu = !valid_ib_mtu(ppd->ibmtu) ? props->max_mtu :
>>>  		mtu_to_enum(ppd->ibmtu, IB_MTU_4096);
>>> -	props->phys_mtu = HFI1_CAP_IS_KSET(AIP) ? hfi1_max_mtu :
>>> -				ib_mtu_enum_to_int(props->max_mtu);
>>> +	props->phys_mtu = hfi1_max_mtu;
>>>  
>>>  	return 0;
>>>  }
>>
>> Fixes: 6d72344cf6c4 ("IB/ipoib: Increase ipoib Datagram mode MTU's upper limit")
>>
>> Can this just get queued up for-next or should I resubmit with the fixes line above?
> 
> Is it OK without the prior patch in the series?

Stands on its own. I think the only other patch we have outstanding right now is
the one about preempt being held across smp_processor_id [1]. That one has some
issues that make it more complicated than it seemed at first. In fact if you
want to drop that from patchworks that's fine and I'll resubmit once we get
things ironed out.

[1]
https://patchwork.kernel.org/project/linux-rdma/patch/20211213141119.177982.15684.stgit@awfm-01.cornelisnetworks.com/

-Denny
Jason Gunthorpe March 5, 2022, 12:24 a.m. UTC | #4
On Tue, Feb 08, 2022 at 02:25:09PM -0500, mike.marciniszyn@cornelisnetworks.com wrote:
> From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
> 
> The AIP code signals the phys_mtu in the following query_port()
> fragment:
> 
> 	props->phys_mtu = HFI1_CAP_IS_KSET(AIP) ? hfi1_max_mtu :
> 				ib_mtu_enum_to_int(props->max_mtu);
> 
> Using the largest MTU possible should not depend on AIP.
> 
> Fix by unconditionally using the hfi1_max_mtu value.
> 
> Reviewed-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
> ---
>  drivers/infiniband/hw/hfi1/verbs.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Applied to for-next, thanks

Jason
diff mbox series

Patch

diff --git a/drivers/infiniband/hw/hfi1/verbs.c b/drivers/infiniband/hw/hfi1/verbs.c
index dc9211f..99d0743 100644
--- a/drivers/infiniband/hw/hfi1/verbs.c
+++ b/drivers/infiniband/hw/hfi1/verbs.c
@@ -1397,8 +1397,7 @@  static int query_port(struct rvt_dev_info *rdi, u32 port_num,
 				      4096 : hfi1_max_mtu), IB_MTU_4096);
 	props->active_mtu = !valid_ib_mtu(ppd->ibmtu) ? props->max_mtu :
 		mtu_to_enum(ppd->ibmtu, IB_MTU_4096);
-	props->phys_mtu = HFI1_CAP_IS_KSET(AIP) ? hfi1_max_mtu :
-				ib_mtu_enum_to_int(props->max_mtu);
+	props->phys_mtu = hfi1_max_mtu;
 
 	return 0;
 }