| Message ID | ab41c34eda793654700ff4b2dce04782620e4ebc.1519067702.git.swise@opengridcomputing.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Mon, Feb 19, 2018 at 08:16:33AM -0800, Steve Wise wrote: > diff --git a/drivers/infiniband/core/cma_priv.h b/drivers/infiniband/core/cma_priv.h > new file mode 100644 > index 0000000..1b6dfbf > +++ b/drivers/infiniband/core/cma_priv.h > @@ -0,0 +1,75 @@ > +/* > + * Copyright (c) 2005 Voltaire Inc. All rights reserved. > + * Copyright (c) 2002-2005, Network Appliance, Inc. All rights reserved. > + * Copyright (c) 1999-2005, Mellanox Technologies, Inc. All rights reserved. > + * Copyright (c) 2005-2006 Intel Corporation. All rights reserved. > + * > + * This software is available to you under a choice of one of two > + * licenses. You may choose to be licensed under the terms of the GNU > + * General Public License (GPL) Version 2, available from the file > + * COPYING in the main directory of this source tree, or the > + * OpenIB.org BSD license below: > + * > + * Redistribution and use in source and binary forms, with or > + * without modification, are permitted provided that the following > + * conditions are met: > + * > + * - Redistributions of source code must retain the above > + * copyright notice, this list of conditions and the following > + * disclaimer. > + * > + * - Redistributions in binary form must reproduce the above > + * copyright notice, this list of conditions and the following > + * disclaimer in the documentation and/or other materials > + * provided with the distribution. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS > + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN > + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN > + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE > + * SOFTWARE. > + */ > + Header guards? And please check patchworks, there is something wrong with how you send patches they get wronly ordered and have wonky dates.. Makes them hard to apply.. 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
> -----Original Message----- > From: Jason Gunthorpe [mailto:jgg@ziepe.ca] > Sent: Monday, February 19, 2018 4:49 PM > To: Steve Wise > Cc: dledford@redhat.com; leon@kernel.org; yishaih@mellanox.com; linux- > rdma@vger.kernel.org > Subject: Re: [PATCH v2 rdma-next 2/9] RDMA/CM: move rdma_id_private to > cma_priv.h > > On Mon, Feb 19, 2018 at 08:16:33AM -0800, Steve Wise wrote: > > > diff --git a/drivers/infiniband/core/cma_priv.h > b/drivers/infiniband/core/cma_priv.h > > new file mode 100644 > > index 0000000..1b6dfbf > > +++ b/drivers/infiniband/core/cma_priv.h > > @@ -0,0 +1,75 @@ > > +/* > > + * Copyright (c) 2005 Voltaire Inc. All rights reserved. > > + * Copyright (c) 2002-2005, Network Appliance, Inc. All rights reserved. > > + * Copyright (c) 1999-2005, Mellanox Technologies, Inc. All rights reserved. > > + * Copyright (c) 2005-2006 Intel Corporation. All rights reserved. > > + * > > + * This software is available to you under a choice of one of two > > + * licenses. You may choose to be licensed under the terms of the GNU > > + * General Public License (GPL) Version 2, available from the file > > + * COPYING in the main directory of this source tree, or the > > + * OpenIB.org BSD license below: > > + * > > + * Redistribution and use in source and binary forms, with or > > + * without modification, are permitted provided that the following > > + * conditions are met: > > + * > > + * - Redistributions of source code must retain the above > > + * copyright notice, this list of conditions and the following > > + * disclaimer. > > + * > > + * - Redistributions in binary form must reproduce the above > > + * copyright notice, this list of conditions and the following > > + * disclaimer in the documentation and/or other materials > > + * provided with the distribution. > > + * > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY > KIND, > > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE > WARRANTIES OF > > + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR > COPYRIGHT HOLDERS > > + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN > AN > > + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF > OR IN > > + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS > IN THE > > + * SOFTWARE. > > + */ > > + > > Header guards? > Oops. Yes. > And please check patchworks, there is something wrong with how you send > patches they get wronly ordered and have wonky dates.. Makes them hard > to apply.. I'm sending them with sendmail. I'll figure it out... Steve -- 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 Mon, Feb 19, 2018 at 05:09:15PM -0600, Steve Wise wrote: > > And please check patchworks, there is something wrong with how you send > > patches they get wronly ordered and have wonky dates.. Makes them hard > > to apply.. > > I'm sending them with sendmail. I'll figure it out... So do I, I just have git-send-email call it for me :) [sendemail] smtpserver = /usr/sbin/sendmail confirm = always from = Jason Gunthorpe <jgg@ziepe.ca> envelopeSender = Jason Gunthorpe <jgg@ziepe.ca> suppresscc = self 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 Mon, 2018-02-19 at 16:11 -0700, Jason Gunthorpe wrote: > On Mon, Feb 19, 2018 at 05:09:15PM -0600, Steve Wise wrote: > > > > And please check patchworks, there is something wrong with how you send > > > patches they get wronly ordered and have wonky dates.. Makes them hard > > > to apply.. > > > > I'm sending them with sendmail. I'll figure it out... > > So do I, I just have git-send-email call it for me :) > > [sendemail] > smtpserver = /usr/sbin/sendmail > confirm = always > from = Jason Gunthorpe <jgg@ziepe.ca> > envelopeSender = Jason Gunthorpe <jgg@ziepe.ca> > suppresscc = self > > Jason I think it's the size of the patch. I've seen this before. Big patches can end up landing in patchworks out of order, and I think it's because the mailman queues on vger simply send the files, so smaller patches, even though queued later, can end up ahead of bigger patches because they deliver to recipients faster.
On Mon, 2018-02-19 at 22:53 -0500, Doug Ledford wrote: > On Mon, 2018-02-19 at 16:11 -0700, Jason Gunthorpe wrote: > > On Mon, Feb 19, 2018 at 05:09:15PM -0600, Steve Wise wrote: > > > > > > And please check patchworks, there is something wrong with how you send > > > > patches they get wronly ordered and have wonky dates.. Makes them hard > > > > to apply.. > > > > > > I'm sending them with sendmail. I'll figure it out... > > > > So do I, I just have git-send-email call it for me :) > > > > [sendemail] > > smtpserver = /usr/sbin/sendmail > > confirm = always > > from = Jason Gunthorpe <jgg@ziepe.ca> > > envelopeSender = Jason Gunthorpe <jgg@ziepe.ca> > > suppresscc = self > > > > Jason > > I think it's the size of the patch. I've seen this before. Big patches > can end up landing in patchworks out of order, and I think it's because > the mailman queues on vger simply send the files, so smaller patches, > even though queued later, can end up ahead of bigger patches because > they deliver to recipients faster. > Ok, after looking, none of these patches are large enough to cause the effect I talked about. It's normally things like 10,000 line binary blob patches that get obviously out of sequence. Everything here is small enough I would expect it to deliver in order, so I don't know what's going on here except maybe the specific smtp server Steve is using might be reordering things? There is another option, but it only applies to direct and list recipients such as myself and Jason. I filter my incoming email to remove duplicates. Sometimes the list email arrives first and sometimes the direct email arrives first. Just depends. Either way, they are all filtered to the same folder and de-duped (which means if you *really* want to get my attention, you email me without including a mailing list). But, that's not it either. Looking at this thread, the cover letter is from Steve at 2:15pm. However, patch 2/9 is from Steve at 11:16am. See for yourself: Cover Letter headers: Received: from mx1.redhat.com (ext-mx03.extmail.prod.ext.phx2.redhat.com [10.5.110.27]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4DD2365620 for <dledford@redhat.com>; Mon, 19 Feb 2018 19:17:38 +0000 (UTC) Received: from smtp.opengridcomputing.com (opengridcomputing.com [70.118.0.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 09AEB81127 for <dledford@redhat.com>; Mon, 19 Feb 2018 19:17:37 +0000 (UTC) Received: by smtp.opengridcomputing.com (Postfix, from userid 503) id 92A272B977; Mon, 19 Feb 2018 13:17:35 -0600 (CST) Message-id: <cover.1519067702.git.swise@opengridcomputing.com> From: Steve Wise <swise@opengridcomputing.com> Date: Mon, 19 Feb 2018 11:15:02 -0800 (02/19/2018 02:15:02 PM) Subject: [PATCH v2 rdma-next 0/9] cm_id, cq, mr, and pd resource tracking Patch 2/9 headers: Received: from mx1.redhat.com (ext-mx03.extmail.prod.ext.phx2.redhat.com [10.5.110.27]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 636C260BE6 for <dledford@redhat.com>; Mon, 19 Feb 2018 19:17:47 +0000 (UTC) Received: from smtp.opengridcomputing.com (opengridcomputing.com [70.118.0.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7C26E80F9C for <dledford@redhat.com>; Mon, 19 Feb 2018 19:17:46 +0000 (UTC) Received: by smtp.opengridcomputing.com (Postfix, from userid 503) id AAFBF2B9B8; Mon, 19 Feb 2018 13:17:45 -0600 (CST) Message-id: <ab41c34eda793654700ff4b2dce04782620e4ebc.1519067702.git.swi se@opengridcomputing.com> In-reply-to: <cover.1519067702.git.swise@opengridcomputing.com> References: <cover.1519067702.git.swise@opengridcomputing.com> From: Steve Wise <swise@opengridcomputing.com> Date: Mon, 19 Feb 2018 08:16:33 -0800 (02/19/2018 11:16:33 AM) Subject: [PATCH v2 rdma-next 2/9] RDMA/CM: move rdma_id_private to cma_priv.h If you notice, once the messages make it to smtp.opengridcomputing.com, the timestamps are as you would expect and increment in reasonable steps , but the timestamps from Steve's machine are wonky. So, there is something funky on Steve's machine with his sending timestamps. Steve, are you taking a long time to edit files or something? Or something else that would throw off the git send-email process?
> > On Mon, 2018-02-19 at 22:53 -0500, Doug Ledford wrote: > > On Mon, 2018-02-19 at 16:11 -0700, Jason Gunthorpe wrote: > > > On Mon, Feb 19, 2018 at 05:09:15PM -0600, Steve Wise wrote: > > > > > > > > And please check patchworks, there is something wrong with how you > send > > > > > patches they get wronly ordered and have wonky dates.. Makes them > hard > > > > > to apply.. > > > > > > > > I'm sending them with sendmail. I'll figure it out... > > > > > > So do I, I just have git-send-email call it for me :) > > > > > > [sendemail] > > > smtpserver = /usr/sbin/sendmail > > > confirm = always > > > from = Jason Gunthorpe <jgg@ziepe.ca> > > > envelopeSender = Jason Gunthorpe <jgg@ziepe.ca> > > > suppresscc = self > > > > > > Jason > > > > I think it's the size of the patch. I've seen this before. Big patches > > can end up landing in patchworks out of order, and I think it's because > > the mailman queues on vger simply send the files, so smaller patches, > > even though queued later, can end up ahead of bigger patches because > > they deliver to recipients faster. > > > > Ok, after looking, none of these patches are large enough to cause the > effect I talked about. It's normally things like 10,000 line binary > blob patches that get obviously out of sequence. Everything here is > small enough I would expect it to deliver in order, so I don't know > what's going on here except maybe the specific smtp server Steve is > using might be reordering things? > > There is another option, but it only applies to direct and list > recipients such as myself and Jason. I filter my incoming email to > remove duplicates. Sometimes the list email arrives first and sometimes > the direct email arrives first. Just depends. Either way, they are all > filtered to the same folder and de-duped (which means if you *really* > want to get my attention, you email me without including a mailing > list). > > But, that's not it either. Looking at this thread, the cover letter is > from Steve at 2:15pm. However, patch 2/9 is from Steve at 11:16am. See > for yourself: > > Cover Letter headers: > > Received: from mx1.redhat.com (ext- > mx03.extmail.prod.ext.phx2.redhat.com > [10.5.110.27]) > by smtp.corp.redhat.com (Postfix) with ESMTPS id 4DD2365620 > for <dledford@redhat.com>; Mon, 19 Feb 2018 19:17:38 +0000 (UTC) > Received: from smtp.opengridcomputing.com (opengridcomputing.com > [70.118.0.34]) > (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 > bits)) > (No client certificate requested) > by mx1.redhat.com (Postfix) with ESMTPS id 09AEB81127 > for <dledford@redhat.com>; Mon, 19 Feb 2018 19:17:37 +0000 (UTC) > Received: by smtp.opengridcomputing.com (Postfix, from userid 503) > id 92A272B977; Mon, 19 Feb 2018 13:17:35 -0600 (CST) > Message-id: <cover.1519067702.git.swise@opengridcomputing.com> > From: Steve Wise <swise@opengridcomputing.com> > Date: Mon, 19 Feb 2018 11:15:02 -0800 (02/19/2018 02:15:02 PM) > Subject: [PATCH v2 rdma-next 0/9] cm_id, cq, mr, and pd resource > tracking > > Patch 2/9 headers: > > Received: from mx1.redhat.com (ext- > mx03.extmail.prod.ext.phx2.redhat.com > [10.5.110.27]) > by smtp.corp.redhat.com (Postfix) with ESMTPS id 636C260BE6 > for <dledford@redhat.com>; Mon, 19 Feb 2018 19:17:47 +0000 (UTC) > Received: from smtp.opengridcomputing.com (opengridcomputing.com > [70.118.0.34]) > (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 > bits)) > (No client certificate requested) > by mx1.redhat.com (Postfix) with ESMTPS id 7C26E80F9C > for <dledford@redhat.com>; Mon, 19 Feb 2018 19:17:46 +0000 (UTC) > Received: by smtp.opengridcomputing.com (Postfix, from userid 503) > id AAFBF2B9B8; Mon, 19 Feb 2018 13:17:45 -0600 (CST) > Message-id: > <ab41c34eda793654700ff4b2dce04782620e4ebc.1519067702.git.swi > se@opengridcomputing.com> > In-reply-to: <cover.1519067702.git.swise@opengridcomputing.com> > References: <cover.1519067702.git.swise@opengridcomputing.com> > From: Steve Wise <swise@opengridcomputing.com> > Date: Mon, 19 Feb 2018 08:16:33 -0800 (02/19/2018 11:16:33 AM) > Subject: [PATCH v2 rdma-next 2/9] RDMA/CM: move rdma_id_private to > cma_priv.h > > If you notice, once the messages make it to smtp.opengridcomputing.com, > the timestamps are as you would expect and increment in reasonable steps > , but the timestamps from Steve's machine are wonky. So, there is > something funky on Steve's machine with his sending timestamps. Steve, > are you taking a long time to edit files or something? Or something > else that would throw off the git send-email process? Oh I think I know what's happening. I created these patches on a machine that is in PST timezone, and the clock on the system might not even be setup correctly. I use git format-patch for that. I then pull the patches to Texas (CST timezone) and submit them to my email server via sendmail. So the "Date: " in the patch is from the PST patch creation time, and the "Received: " times logged by ogc are CST. Why is this confusing patchworks though? If it uses the patch dates only or the received dates only, it should be in-order, I think. -- 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 Tue, 2018-02-20 at 09:18 -0600, Steve Wise wrote: > > > > On Mon, 2018-02-19 at 22:53 -0500, Doug Ledford wrote: > > > On Mon, 2018-02-19 at 16:11 -0700, Jason Gunthorpe wrote: > > > > On Mon, Feb 19, 2018 at 05:09:15PM -0600, Steve Wise wrote: > > > > > > > > > > And please check patchworks, there is something wrong with how you > > > > send > > > > > > patches they get wronly ordered and have wonky dates.. Makes them > > > > hard > > > > > > to apply.. > > > > > > > > > > I'm sending them with sendmail. I'll figure it out... > > > > > > > > So do I, I just have git-send-email call it for me :) > > > > > > > > [sendemail] > > > > smtpserver = /usr/sbin/sendmail > > > > confirm = always > > > > from = Jason Gunthorpe <jgg@ziepe.ca> > > > > envelopeSender = Jason Gunthorpe <jgg@ziepe.ca> > > > > suppresscc = self > > > > > > > > Jason > > > > > > I think it's the size of the patch. I've seen this before. Big patches > > > can end up landing in patchworks out of order, and I think it's because > > > the mailman queues on vger simply send the files, so smaller patches, > > > even though queued later, can end up ahead of bigger patches because > > > they deliver to recipients faster. > > > > > > > Ok, after looking, none of these patches are large enough to cause the > > effect I talked about. It's normally things like 10,000 line binary > > blob patches that get obviously out of sequence. Everything here is > > small enough I would expect it to deliver in order, so I don't know > > what's going on here except maybe the specific smtp server Steve is > > using might be reordering things? > > > > There is another option, but it only applies to direct and list > > recipients such as myself and Jason. I filter my incoming email to > > remove duplicates. Sometimes the list email arrives first and sometimes > > the direct email arrives first. Just depends. Either way, they are all > > filtered to the same folder and de-duped (which means if you *really* > > want to get my attention, you email me without including a mailing > > list). > > > > But, that's not it either. Looking at this thread, the cover letter is > > from Steve at 2:15pm. However, patch 2/9 is from Steve at 11:16am. See > > for yourself: > > > > Cover Letter headers: > > From: Steve Wise <swise@opengridcomputing.com> > > Date: Mon, 19 Feb 2018 11:15:02 -0800 (02/19/2018 02:15:02 PM) > > Subject: [PATCH v2 rdma-next 0/9] cm_id, cq, mr, and pd resource > > tracking > > > > Patch 2/9 headers: > > From: Steve Wise <swise@opengridcomputing.com> > > Date: Mon, 19 Feb 2018 08:16:33 -0800 (02/19/2018 11:16:33 AM) > > Subject: [PATCH v2 rdma-next 2/9] RDMA/CM: move rdma_id_private to > > cma_priv.h > > > > > Oh I think I know what's happening. I created these patches on a machine that is in PST timezone, and the clock on the system might not even be setup correctly. I use git format-patch for that. I then pull the patches to Texas (CST timezone) and submit them to my email server via sendmail. So the "Date: " in the patch is from the PST patch creation time, and the "Received: " times logged by ogc are CST. > > Why is this confusing patchworks though? If it uses the patch dates only or the received dates only, it should be in-order, I think. Even that doesn't explain the above. There are two vastly different timestamps on the emails. Patchworks is evidently using the Date: header, and on the two different files coming from the computer in the PST timezone, the times are different by 3 hours.
> > > > > Oh I think I know what's happening. I created these patches on a machine > that is in PST timezone, and the clock on the system might not even be setup > correctly. I use git format-patch for that. I then pull the patches to Texas > (CST timezone) and submit them to my email server via sendmail. So the > "Date: " in the patch is from the PST patch creation time, and the "Received: " > times logged by ogc are CST. > > > > Why is this confusing patchworks though? If it uses the patch dates only or > the received dates only, it should be in-order, I think. > > Even that doesn't explain the above. There are two vastly different > timestamps on the emails. Patchworks is evidently using the Date: > header, and on the two different files coming from the computer in the > PST timezone, the times are different by 3 hours. > Thanks Doug. Guys, I'll have this figured out for posting v3. Sorry for the pain... Steve. -- 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
> > > > > > But, that's not it either. Looking at this thread, the cover letter is > > > from Steve at 2:15pm. However, patch 2/9 is from Steve at 11:16am. See > > > for yourself: > > > > > > Cover Letter headers: > > > From: Steve Wise <swise@opengridcomputing.com> > > > Date: Mon, 19 Feb 2018 11:15:02 -0800 (02/19/2018 02:15:02 PM) > > > Subject: [PATCH v2 rdma-next 0/9] cm_id, cq, mr, and pd resource > > > tracking > > > > > > Patch 2/9 headers: > > > From: Steve Wise <swise@opengridcomputing.com> > > > Date: Mon, 19 Feb 2018 08:16:33 -0800 (02/19/2018 11:16:33 AM) > > > Subject: [PATCH v2 rdma-next 2/9] RDMA/CM: move rdma_id_private to > > > cma_priv.h > > > > > > > > Oh I think I know what's happening. I created these patches on a machine > that is in PST timezone, and the clock on the system might not even be setup > correctly. I use git format-patch for that. I then pull the patches to Texas > (CST timezone) and submit them to my email server via sendmail. So the > "Date: " in the patch is from the PST patch creation time, and the "Received: " > times logged by ogc are CST. > > > > Why is this confusing patchworks though? If it uses the patch dates only or > the received dates only, it should be in-order, I think. > > Even that doesn't explain the above. There are two vastly different > timestamps on the emails. Patchworks is evidently using the Date: > header, and on the two different files coming from the computer in the > PST timezone, the times are different by 3 hours. I think the problem was caused by me using stg (Stacked Git), and perhaps how I rebased the series for the v2 submission. The author dates in the git branch are screwed up. Here is the git log showing the author dates from the branch I used to generate the patches: [root@stevo1 restrack-v2]# git log --abbrev=12 --pretty=format:'%h %ad %s' 2f08ee363fe0.. ad0d40dceeb9 Mon Feb 19 08:30:03 2018 -0800 RDMA/nldev: provide detailed PD information a6dee1428bc9 Mon Feb 19 10:24:24 2018 -0800 mlx4_ib: zero out struct ib_pd when allocating 74dfc0aa2480 Mon Feb 19 08:22:11 2018 -0800 RDMA/nldev: provide detailed MR information 0dbbb2a638a5 Mon Feb 19 10:58:54 2018 -0800 mlx4_ib: set user mr attributes in struct ib_mr bd9f59299fc3 Mon Feb 19 08:22:10 2018 -0800 iw_cxgb4: initialize ib_mr fields for user mrs 7317eccc7687 Mon Feb 19 08:22:00 2018 -0800 RDMA/nldev: provide detailed CQ information 28891e0ffb01 Mon Feb 19 08:16:34 2018 -0800 RDMA/nldev: provide detailed CM_ID information ab41c34eda79 Mon Feb 19 08:16:33 2018 -0800 RDMA/CM: move rdma_id_private to cma_priv.h 43f56a109bc3 Mon Feb 19 09:24:16 2018 -0800 RDMA/restrack: clean up res_to_dev() The commit dates look ok though: [root@stevo1 restrack-v2]# git log --abbrev=12 --pretty=format:'%h %cd %s' 2f08ee363fe0.. ad0d40dceeb9 Mon Feb 19 11:02:30 2018 -0800 RDMA/nldev: provide detailed PD information a6dee1428bc9 Mon Feb 19 11:02:29 2018 -0800 mlx4_ib: zero out struct ib_pd when allocating 74dfc0aa2480 Mon Feb 19 11:02:29 2018 -0800 RDMA/nldev: provide detailed MR information 0dbbb2a638a5 Mon Feb 19 10:58:54 2018 -0800 mlx4_ib: set user mr attributes in struct ib_mr bd9f59299fc3 Mon Feb 19 09:29:51 2018 -0800 iw_cxgb4: initialize ib_mr fields for user mrs 7317eccc7687 Mon Feb 19 09:29:49 2018 -0800 RDMA/nldev: provide detailed CQ information 28891e0ffb01 Mon Feb 19 09:26:41 2018 -0800 RDMA/nldev: provide detailed CM_ID information ab41c34eda79 Mon Feb 19 09:26:38 2018 -0800 RDMA/CM: move rdma_id_private to cma_priv.h 43f56a109bc3 Mon Feb 19 09:24:16 2018 -0800 RDMA/restrack: clean up res_to_dev() So I need to fix my process and not screw up the author dates. Sorry about this. Steve. -- 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 Wed, 2018-02-21 at 06:48 -0600, Steve Wise wrote:
> So I need to fix my process and not screw up the author dates. Sorry about this.
No worries, we likes a good mystery from times to times we does we does
;-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c index e66963c..203519e 100644 --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband/core/cma.c @@ -62,6 +62,7 @@ #include <rdma/iw_cm.h> #include "core_priv.h" +#include "cma_priv.h" MODULE_AUTHOR("Sean Hefty"); MODULE_DESCRIPTION("Generic RDMA CM Agent"); @@ -327,46 +328,6 @@ struct ib_device *cma_get_ib_dev(struct cma_device *cma_dev) * We do this by disabling removal notification while a callback is in process, * and reporting it after the callback completes. */ -struct rdma_id_private { - struct rdma_cm_id id; - - struct rdma_bind_list *bind_list; - struct hlist_node node; - struct list_head list; /* listen_any_list or cma_device.list */ - struct list_head listen_list; /* per device listens */ - struct cma_device *cma_dev; - struct list_head mc_list; - - int internal_id; - enum rdma_cm_state state; - spinlock_t lock; - struct mutex qp_mutex; - - struct completion comp; - atomic_t refcount; - struct mutex handler_mutex; - - int backlog; - int timeout_ms; - struct ib_sa_query *query; - int query_id; - union { - struct ib_cm_id *ib; - struct iw_cm_id *iw; - } cm_id; - - u32 seq_num; - u32 qkey; - u32 qp_num; - pid_t owner; - u32 options; - u8 srq; - u8 tos; - bool tos_set; - u8 reuseaddr; - u8 afonly; - enum ib_gid_type gid_type; -}; struct cma_multicast { struct rdma_id_private *id_priv; diff --git a/drivers/infiniband/core/cma_priv.h b/drivers/infiniband/core/cma_priv.h new file mode 100644 index 0000000..1b6dfbf --- /dev/null +++ b/drivers/infiniband/core/cma_priv.h @@ -0,0 +1,75 @@ +/* + * Copyright (c) 2005 Voltaire Inc. All rights reserved. + * Copyright (c) 2002-2005, Network Appliance, Inc. All rights reserved. + * Copyright (c) 1999-2005, Mellanox Technologies, Inc. All rights reserved. + * Copyright (c) 2005-2006 Intel Corporation. All rights reserved. + * + * This software is available to you under a choice of one of two + * licenses. You may choose to be licensed under the terms of the GNU + * General Public License (GPL) Version 2, available from the file + * COPYING in the main directory of this source tree, or the + * OpenIB.org BSD license below: + * + * Redistribution and use in source and binary forms, with or + * without modification, are permitted provided that the following + * conditions are met: + * + * - Redistributions of source code must retain the above + * copyright notice, this list of conditions and the following + * disclaimer. + * + * - Redistributions in binary form must reproduce the above + * copyright notice, this list of conditions and the following + * disclaimer in the documentation and/or other materials + * provided with the distribution. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE + * SOFTWARE. + */ + +struct rdma_id_private { + struct rdma_cm_id id; + + struct rdma_bind_list *bind_list; + struct hlist_node node; + struct list_head list; /* listen_any_list or cma_device.list */ + struct list_head listen_list; /* per device listens */ + struct cma_device *cma_dev; + struct list_head mc_list; + + int internal_id; + enum rdma_cm_state state; + spinlock_t lock; + struct mutex qp_mutex; + + struct completion comp; + atomic_t refcount; + struct mutex handler_mutex; + + int backlog; + int timeout_ms; + struct ib_sa_query *query; + int query_id; + union { + struct ib_cm_id *ib; + struct iw_cm_id *iw; + } cm_id; + + u32 seq_num; + u32 qkey; + u32 qp_num; + pid_t owner; + u32 options; + u8 srq; + u8 tos; + bool tos_set; + u8 reuseaddr; + u8 afonly; + enum ib_gid_type gid_type; +};
Move struct rdma_id_private to a new header cma_priv.h so the resource tracking services in core/nldev.c can read useful information about cm_ids. Signed-off-by: Steve Wise <swise@opengridcomputing.com> --- drivers/infiniband/core/cma.c | 41 +-------------------- drivers/infiniband/core/cma_priv.h | 75 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 76 insertions(+), 40 deletions(-) create mode 100644 drivers/infiniband/core/cma_priv.h