| Message ID | 1472774969-18997-10-git-send-email-knut.omang@oracle.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Fri, Sep 02, 2016 at 02:09:29AM +0200, Knut Omang wrote: > Some Infiniband HCAs need to know if a QP is going to > be used for Ethernet over IB (EOIB). You will have to send this after your driver. I recommend a patch proposing this functionality with your driver as the example implementation, along with a kernel user, as mellanox typically does. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2016-09-01 at 20:17 -0600, Jason Gunthorpe wrote: > On Fri, Sep 02, 2016 at 02:09:29AM +0200, Knut Omang wrote: > > Some Infiniband HCAs need to know if a QP is going to > > be used for Ethernet over IB (EOIB). > > You will have to send this after your driver. I recommend a patch > proposing this functionality with your driver as the example > implementation, along with a kernel user, as mellanox typically does. It's a bit of a chicken and egg situation since the driver depends on the patches. If I can 'tick off' this bit soon, I can move ahead and get to the send the driver too. There's not much info in the driver - it just forwards that bit to a hardware bit and it all happens from there. But hardware needs to know when to set that bit, as it is only valid when operating as transport for Ethernet. Please - it would be a big help for me (saving a lot of work down the line that is better spent working with the community than with handling more version issues later) if I can get an indication that just that bit would be acceptable 8-D ... Thanks, Knut > Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2016-09-02 at 07:04 +0200, Knut Omang wrote: > On Thu, 2016-09-01 at 20:17 -0600, Jason Gunthorpe wrote: > > > > On Fri, Sep 02, 2016 at 02:09:29AM +0200, Knut Omang wrote: > > > > > > Some Infiniband HCAs need to know if a QP is going to > > > be used for Ethernet over IB (EOIB). > > You will have to send this after your driver. I recommend a patch > > proposing this functionality with your driver as the example > > implementation, along with a kernel user, as mellanox typically does. > It's a bit of a chicken and egg situation since the driver > depends on the patches. If I can 'tick off' this bit soon, I can move ahead and > get to the send the driver too. > > There's not much info in the driver - it just forwards that bit to a hardware bit > and it all happens from there. But hardware needs to know when to set that bit, > as it is only valid when operating as transport for Ethernet. > > Please - it would be a big help for me (saving a lot of work down the line that > is better spent working with the community than with handling more version issues later) > if I can get an indication that just that bit would be acceptable 8-D ... I will add the following further justification to the commit message for v2: Support for encapsulation of Ethernet over IB (EoIB) is a generic feature where different HCA implementations can include different special features. One example is that if the HCA knows the QP is going to be used for Ethernet, the implementation can ensure that all messages sent on this QP represents a properly formatted encapsulation of Ethernet frames with legal header values. Or the HCA can perform the encapsulation itself. Knut -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9/2/2016 4:00 AM, Knut Omang wrote: > On Fri, 2016-09-02 at 07:04 +0200, Knut Omang wrote: >> On Thu, 2016-09-01 at 20:17 -0600, Jason Gunthorpe wrote: >>> >>> On Fri, Sep 02, 2016 at 02:09:29AM +0200, Knut Omang wrote: >>>> >>>> Some Infiniband HCAs need to know if a QP is going to >>>> be used for Ethernet over IB (EOIB). >>> You will have to send this after your driver. I recommend a patch >>> proposing this functionality with your driver as the example >>> implementation, along with a kernel user, as mellanox typically does. >> It's a bit of a chicken and egg situation since the driver >> depends on the patches. If I can 'tick off' this bit soon, I can move ahead and >> get to the send the driver too. >> >> There's not much info in the driver - it just forwards that bit to a hardware bit >> and it all happens from there. But hardware needs to know when to set that bit, >> as it is only valid when operating as transport for Ethernet. >> Right. It comes down to removing mask filter at verbs layer and letting driver get the full view of it so that it can better deal with it based on information. >> Please - it would be a big help for me (saving a lot of work down the line that >> is better spent working with the community than with handling more version issues later) >> if I can get an indication that just that bit would be acceptable 8-D ... > > I will add the following further justification to the commit message for v2: > > Support for encapsulation of Ethernet over IB (EoIB) is a generic feature > where different HCA implementations can include different special features. > One example is that if the HCA knows the QP is going to be used for Ethernet, > the implementation can ensure that all messages sent on this QP represents > a properly formatted encapsulation of Ethernet frames with legal header values. > Or the HCA can perform the encapsulation itself. > Don't want to hijack your patch but I also have seen another need where ULP needs to pass additional information to driver for creating RC qp with couple of add-ons . My current thought is to use reserved QP flag bits (bits 26-31, for low level drivers' internal use) but wanted to check if there is any objection to it. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 02, 2016 at 01:00:57PM +0200, Knut Omang wrote: > On Fri, 2016-09-02 at 07:04 +0200, Knut Omang wrote: > > On Thu, 2016-09-01 at 20:17 -0600, Jason Gunthorpe wrote: > > > > > > On Fri, Sep 02, 2016 at 02:09:29AM +0200, Knut Omang wrote: > > > > > > > > Some Infiniband HCAs need to know if a QP is going to > > > > be used for Ethernet over IB (EOIB). > > > You will have to send this after your driver. I recommend a patch > > > proposing this functionality with your driver as the example > > > implementation, along with a kernel user, as mellanox typically does. > > It's a bit of a chicken and egg situation since the driver > > depends on the patches. If I can 'tick off' this bit soon, I can move ahead and > > get to the send the driver too. > > > > There's not much info in the driver - it just forwards that bit to a hardware bit > > and it all happens from there. But hardware needs to know when to set that bit, > > as it is only valid when operating as transport for Ethernet. > > > > Please - it would be a big help for me (saving a lot of work down the line that > > is better spent working with the community than with handling more version issues later) > > if I can get an indication that just that bit would be acceptable 8-D ... > > I will add the following further justification to the commit message for v2: > > Support for encapsulation of Ethernet over IB (EoIB) is a generic feature > where different HCA implementations can include different special features. > One example is that if the HCA knows the QP is going to be used for Ethernet, > the implementation can ensure that all messages sent on this QP represents > a properly formatted encapsulation of Ethernet frames with legal header values. > Or the HCA can perform the encapsulation itself. It would be better to remove support for this from your driver in the initial submission. Keep new uAPIs in new driver submissions to an absolute minimum please. And as I said, you need to introduce a kernel user of this bit as well, so the driver alone is not enough. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 02, 2016 at 09:19:43AM -0700, Santosh Shilimkar wrote: > Don't want to hijack your patch but I also have seen another need where > ULP needs to pass additional information to driver for creating > RC qp with couple of add-ons . My current thought is to use reserved > QP flag bits (bits 26-31, for low level drivers' internal use) Nope, absolutely not. Propose an actual verbs API extensions for what you want to do just like Mellanox has been doing. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9/2/2016 10:11 AM, Jason Gunthorpe wrote: > On Fri, Sep 02, 2016 at 09:19:43AM -0700, Santosh Shilimkar wrote: > >> Don't want to hijack your patch but I also have seen another need where >> ULP needs to pass additional information to driver for creating >> RC qp with couple of add-ons . My current thought is to use reserved >> QP flag bits (bits 26-31, for low level drivers' internal use) > > Nope, absolutely not. > > Propose an actual verbs API extensions for what you want to do just > like Mellanox has been doing. > Thanks Jason for comments. Will do !! Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2016-09-02 at 10:34 -0600, Jason Gunthorpe wrote: > On Fri, Sep 02, 2016 at 01:00:57PM +0200, Knut Omang wrote: > > On Fri, 2016-09-02 at 07:04 +0200, Knut Omang wrote: > > > On Thu, 2016-09-01 at 20:17 -0600, Jason Gunthorpe wrote: > > > > > > > > On Fri, Sep 02, 2016 at 02:09:29AM +0200, Knut Omang wrote: > > > > > > > > > > Some Infiniband HCAs need to know if a QP is going to > > > > > be used for Ethernet over IB (EOIB). > > > > You will have to send this after your driver. I recommend a patch > > > > proposing this functionality with your driver as the example > > > > implementation, along with a kernel user, as mellanox typically does. > > > It's a bit of a chicken and egg situation since the driver > > > depends on the patches. If I can 'tick off' this bit soon, I can move ahead and > > > get to the send the driver too. > > > > > > There's not much info in the driver - it just forwards that bit to a hardware bit > > > and it all happens from there. But hardware needs to know when to set that bit, > > > as it is only valid when operating as transport for Ethernet. > > > > > > Please - it would be a big help for me (saving a lot of work down the line that > > > is better spent working with the community than with handling more version issues later) > > > if I can get an indication that just that bit would be acceptable 8-D ... > > > > I will add the following further justification to the commit message for v2: > > > > Support for encapsulation of Ethernet over IB (EoIB) is a generic feature > > where different HCA implementations can include different special features. > > One example is that if the HCA knows the QP is going to be used for Ethernet, > > the implementation can ensure that all messages sent on this QP represents > > a properly formatted encapsulation of Ethernet frames with legal header values. > > Or the HCA can perform the encapsulation itself. > > It would be better to remove support for this from your driver in the > initial submission. Ok, will do. > Keep new uAPIs in new driver submissions to an absolute minimum please. I completely agree with you that APIs need a lot of care and consideration, rest assure ;-) > And as I said, you need to introduce a kernel user of this bit as > well, so the driver alone is not enough. Ok. The Ethernet driver using this is outside of my control. Knut > > Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h index 093d68e..d6f3f55 100644 --- a/include/rdma/ib_verbs.h +++ b/include/rdma/ib_verbs.h @@ -991,6 +991,7 @@ enum ib_qp_create_flags { IB_QP_CREATE_SIGNATURE_EN = 1 << 6, IB_QP_CREATE_USE_GFP_NOIO = 1 << 7, IB_QP_CREATE_SCATTER_FCS = 1 << 8, + IB_QP_CREATE_EOIB = 1 << 9, /* reserve bits 26-31 for low level drivers' internal use */ IB_QP_CREATE_RESERVED_START = 1 << 26, IB_QP_CREATE_RESERVED_END = 1 << 31,
Some Infiniband HCAs need to know if a QP is going to be used for Ethernet over IB (EOIB). Signed-off-by: Knut Omang <knut.omang@oracle.com> --- include/rdma/ib_verbs.h | 1 + 1 file changed, 1 insertion(+)