* Re: [PATCH V2 for-next 0/8] Bug Fixes and Code Improvement in HNS driver
From: Doug Ledford @ 2016-10-13 11:57 UTC (permalink / raw)
To: Salil Mehta, David Miller
Cc: Zhuangyuzeng (Yisen), Huwei (Xavier), oulijun,
mehta.salil.lnk@gmail.com, linux-rdma@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Linuxarm
In-Reply-To: <F4CC6FACFEB3C54C9141D49AD221F7F91A74F326@lhreml503-mbx>
[-- Attachment #1.1: Type: text/plain, Size: 1595 bytes --]
On 10/13/2016 7:26 AM, Salil Mehta wrote:
>> -----Original Message-----
>> From: David Miller [mailto:davem@davemloft.net]
>> Sent: Friday, September 30, 2016 6:34 AM
>> To: Salil Mehta
>> Cc: dledford@redhat.com; Zhuangyuzeng (Yisen); Huwei (Xavier); oulijun;
>> mehta.salil.lnk@gmail.com; linux-rdma@vger.kernel.org;
>> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
>> Subject: Re: [PATCH V2 for-next 0/8] Bug Fixes and Code Improvement in
>> HNS driver
>>
>> From: Salil Mehta <salil.mehta@huawei.com>
>> Date: Thu, 29 Sep 2016 18:09:08 +0100
>>
>>> This patch-set introduces fix to some Bugs, potential problems
>>> and code improvements identified during internal review and
>>> testing of Hisilicon Network Subsystem driver.
>>>
>>> Submit Change
>>> V1->V2: This addresses the feedbacks provided by David Miller
>>> and Doug Ledford
>>
>> So Doug my understanding is if this makes it through review
> Hi Dave,
> A gentle reminder regarding this. I was wondering if you think these
> have been reviewed enough and by any chance these patches can be included
> in current 4.9 merge window. This will save us a lot of effort.
>
> As I understand Doug is waiting for your review approval on this
> patch-set.
I am, and I was just getting ready to ask again today myself.
> Thanks in anticipation
> Best regards
> Salil
>> this is going to be merged into your tree, you prepare a
>> branch for me, and then I pull from that?
>>
>> Thanks in advance.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [bug report] IB/hns: Add driver files for hns RoCE driver
From: oulijun @ 2016-10-13 13:18 UTC (permalink / raw)
To: Dan Carpenter, Doug Ledford; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161013114341.GA8275@mwanda>
在 2016/10/13 19:43, Dan Carpenter 写道:
> Hello oulijun,
>
> The patch 9a4435375cd1: "IB/hns: Add driver files for hns RoCE
> driver" from Jul 21, 2016, leads to the following static checker
> warning:
>
> drivers/infiniband/hw/hns/hns_roce_mr.c:575 hns_roce_reg_user_mr()
> warn: no lower bound on 'n'
>
> drivers/infiniband/hw/hns/hns_roce_mr.c
> 542 struct ib_mr *hns_roce_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
> 543 u64 virt_addr, int access_flags,
> 544 struct ib_udata *udata)
> 545 {
> 546 struct hns_roce_dev *hr_dev = to_hr_dev(pd->device);
> 547 struct device *dev = &hr_dev->pdev->dev;
> 548 struct hns_roce_mr *mr = NULL;
> 549 int ret = 0;
> 550 int n = 0;
> ^^^^^^^^^
>
> Notice this is signed. Please don't initialize variables to bogus
> values. The compiler has a feature to warn about uninitialized
> variables but by assigning bogus valus to "n" then you are disabling the
> safety checks and potentially hiding bugs.
Thanks, we will fix it in next patch!
>
> 551
> 552 mr = kmalloc(sizeof(*mr), GFP_KERNEL);
> 553 if (!mr)
> 554 return ERR_PTR(-ENOMEM);
> 555
> 556 mr->umem = ib_umem_get(pd->uobject->context, start, length,
> 557 access_flags, 0);
> 558 if (IS_ERR(mr->umem)) {
> 559 ret = PTR_ERR(mr->umem);
> 560 goto err_free;
> 561 }
> 562
> 563 n = ib_umem_page_count(mr->umem);
>
> Depending on the config then ib_umem_page_count() can return -EINVAL.
> Probably it's not possible here. Anyway, probably the right thing is
> to check:
>
> if (n < 0) {
> ret = -EINVAL;
> goto umem;
> }
>
Thanks for your reviewing. I have checked the ib_umem_page_count(), Maybe it
will not return the -EINVAL
when configured CONFIG_INFINIBAND_USER_MEM, the function is
int ib_umem_page_count(struct ib_umem *umem)
{
int shift;
int i;
int n;
struct scatterlist *sg;
if (umem->odp_data)
return ib_umem_num_pages(umem);
shift = ilog2(umem->page_size);
n = 0;
for_each_sg(umem->sg_head.sgl, sg, umem->nmap, i)
n += sg_dma_len(sg) >> shift;
return n;
}
EXPORT_SYMBOL(ib_umem_page_count);
when not configured CONFIG_INFINIBAND_USER_MEM, the function as follow:
static inline int ib_umem_page_count(struct ib_umem *umem) { return 0; }
> It silences the static checker warning.
>
> 564 if (mr->umem->page_size != HNS_ROCE_HEM_PAGE_SIZE) {
> 565 dev_err(dev, "Just support 4K page size but is 0x%x now!\n",
> 566 mr->umem->page_size);
>
> Should we continue here or is there supposed to be a goto umem;?
Thanks, Dan Carpenter
We have taken notice of the problem and have sent a patch to Doug to fix last two problem. the patch link as follow:
https://patchwork.kernel.org/patch/9342015/
>
> 567 }
> 568
> 569 if (n > HNS_ROCE_MAX_MTPT_PBL_NUM) {
> 570 dev_err(dev, " MR len %lld err. MR is limited to 4G at most!\n",
> 571 length);
>
>
> We should be setting "ret = -EINVAL;" here.
Thanks, Dan Carpenter
We have taken notice of the problem and have sent a patch to Doug to fix last two problem. the patch link as follow:
https://patchwork.kernel.org/patch/9342015/
>
> 572 goto err_umem;
> 573 }
> 574
> 575 ret = hns_roce_mr_alloc(hr_dev, to_hr_pd(pd)->pdn, virt_addr, length,
> 576 access_flags, n, mr);
> 577 if (ret)
> 578 goto err_umem;
> 579
>
> regards,
> dan carpenter
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH rdma-next 00/10] Hardware tag matching support
From: Doug Ledford @ 2016-10-13 14:15 UTC (permalink / raw)
To: Hefty, Sean, Leon Romanovsky
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373AB093986-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1441 bytes --]
On 10/7/2016 12:47 PM, Hefty, Sean wrote:
>> For any reasons, I don't see this patch set in your tree. Did I miss
>> it?
>>
>> Thanks
>>
>>>
>>> Thanks,
>>> Artemy & Leon
>>>
>>> Artemy Kovalyov (10):
>>> IB/core: Add XRQ capabilities
>>> IB/core: Make CQ separate part of SRQ context
>>> IB/core: Add new SRQ type IB_SRQT_TAG_MATCHING
>>> IB/uverbs: Expose tag matching capabilties to UAPI
>>> IB/uverbs: Expose XRQ capabilities
>>> IB/uverbs: Add XRQ creation parameter to UAPI
>>> IB/uverbs: Add new SRQ type IB_SRQT_TAG_MATCHING
>>> IB/mlx5: Fill XRQ capabilities
>>> net/mlx5: Add XRQ support
>>> IB/mlx5: Support IB_SRQT_TAG_MATCHING
>
> I was out when these were submitted, so this may have been answered. These patches change the uABI. Have the changes been vetted out by the IBTA or some other standards (I'm using that term loosely) organization?
>
I doubt they have, but they change the kernel to user library API. I'm
not so worried about that since it's entirely under our control. It's
the user library to application API that I would be more concerned with.
As these stand, they look fairly clean to me. Minimal in disruption and
I see no reason other vendors couldn't use this to do tag matching on
their own hardware if they wanted. I'm inclined to take them.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header
From: David Miller @ 2016-10-13 14:24 UTC (permalink / raw)
To: pabeni-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1dbd83dfe7f435eecc5bc460e901b47758280f30.1476206016.git.pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
From: Paolo Abeni <pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date: Tue, 11 Oct 2016 19:15:44 +0200
> After the commit 9207f9d45b0a ("net: preserve IP control block
> during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
> That destroy the IPoIB address information cached there,
> causing a severe performance regression, as better described here:
>
> http://marc.info/?l=linux-kernel&m=146787279825501&w=2
>
> This change moves the data cached by the IPoIB driver from the
> skb control lock into the IPoIB hard header, as done before
> the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
> and use skb->cb to stash LL addresses").
> In order to avoid GRO issue, on packet reception, the IPoIB driver
> stash into the skb a dummy pseudo header, so that the received
> packets have actually a hard header matching the declared length.
> Also the connected mode maximum mtu is reduced by 16 bytes to
> cope with the increased hard header len.
>
> After this commit, IPoIB performances are back to pre-regression
> value.
>
> Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
> Signed-off-by: Paolo Abeni <pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Not providing an accurate hard_header_len causes many problems.
In fact we recently fixed the mlxsw driver to stop doing this.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 00/11] net: Fix netdev adjacency tracking
From: David Ahern @ 2016-10-13 14:32 UTC (permalink / raw)
To: Jiri Pirko
Cc: jiri-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
j.vosburgh-Re5JQEeQqe8AvxtiuMwx3w, vfalico-Re5JQEeQqe8AvxtiuMwx3w,
andy-QlMahl40kYEqcZcGjlUOXw,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
intel-wired-lan-qjLDD68F18P21nG7glBr7A
In-Reply-To: <20161013073424.GB1816-6KJVSR23iU488b5SBfVpbw@public.gmane.org>
On 10/13/16 1:34 AM, Jiri Pirko wrote:
>
> Although I didn't like the "all-list" idea when Veaceslav pushed it
> because it looked to me like a big hammer, it turned out to be very handy
> and quick for traversing neighbours. Why it cannot be fixed?
>
> The walks with possibly hundreds of function calls instead of a single
> list traverse worries me.
>
I have been looking at this code for a week now. Every solution I came up with that solved the original problems introduced new ones -- usually with adjacency remove expecting an adjacency that did not exist. In the end I came to the conclusion it is not possible to maintain an all_adj_list when the upper tree can have multiple paths to the top device. If someone thinks otherwise I am happy to test a patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header
From: Doug Ledford @ 2016-10-13 14:35 UTC (permalink / raw)
To: David Miller, pabeni-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161013.102432.1450901395774429343.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1817 bytes --]
On 10/13/2016 10:24 AM, David Miller wrote:
> From: Paolo Abeni <pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date: Tue, 11 Oct 2016 19:15:44 +0200
>
>> After the commit 9207f9d45b0a ("net: preserve IP control block
>> during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
>> That destroy the IPoIB address information cached there,
>> causing a severe performance regression, as better described here:
>>
>> http://marc.info/?l=linux-kernel&m=146787279825501&w=2
>>
>> This change moves the data cached by the IPoIB driver from the
>> skb control lock into the IPoIB hard header, as done before
>> the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
>> and use skb->cb to stash LL addresses").
>> In order to avoid GRO issue, on packet reception, the IPoIB driver
>> stash into the skb a dummy pseudo header, so that the received
>> packets have actually a hard header matching the declared length.
>> Also the connected mode maximum mtu is reduced by 16 bytes to
>> cope with the increased hard header len.
>>
>> After this commit, IPoIB performances are back to pre-regression
>> value.
>>
>> Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
>> Signed-off-by: Paolo Abeni <pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> Not providing an accurate hard_header_len causes many problems.
>
> In fact we recently fixed the mlxsw driver to stop doing this.
>
Sure, but there are too many users of the cb struct, and whatever
problems you are saying there are by lying about the hard header len are
dwarfed by the problems caused by the inability to store the ll address
anywhere between hard_header and send time.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* RE: Introduction of libqedr to the Consolidated Userspace RDMA Library Repo
From: Amrani, Ram @ 2016-10-13 14:37 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Elior, Ariel,
Kalderon, Michal, Borundia, Rajesh,
dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
In-Reply-To: <SN1PR07MB2207B8BA2C9C9A1FC610DE9FF8D90-mikhvbZlbf8TSoR2DauN2+FPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
> >You will want to look at the various patches I've prepared and ensure
> >you cover off the basic cleanups that have already been done, and that
> >your code compiles warning-free on FC24.
By cleanups, do you mean to make sure the code compiles warning-free under
the various flags mentioned throughout the git log (-Wempty-body and etc.),
or are there other kinds of cleanups that I'm missing?
> >Once you feel everything is ready then post it to the mailing list and
> >send a pull request. For the mailing list you can just split the
> >patches by file..
As we don't have a publically accessed server I cannot do this at the moment (I'm checking how we can set one up).
Is it OK if I send you the update as a series of patches?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header
From: David Miller @ 2016-10-13 14:43 UTC (permalink / raw)
To: dledford; +Cc: pabeni, linux-rdma, sean.hefty, hal.rosenstock, netdev
In-Reply-To: <20ace6ee-b9e4-073c-56e7-29b2c50ae2d5@redhat.com>
From: Doug Ledford <dledford@redhat.com>
Date: Thu, 13 Oct 2016 10:35:35 -0400
> On 10/13/2016 10:24 AM, David Miller wrote:
>> From: Paolo Abeni <pabeni@redhat.com>
>> Date: Tue, 11 Oct 2016 19:15:44 +0200
>>
>>> After the commit 9207f9d45b0a ("net: preserve IP control block
>>> during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
>>> That destroy the IPoIB address information cached there,
>>> causing a severe performance regression, as better described here:
>>>
>>> http://marc.info/?l=linux-kernel&m=146787279825501&w=2
>>>
>>> This change moves the data cached by the IPoIB driver from the
>>> skb control lock into the IPoIB hard header, as done before
>>> the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
>>> and use skb->cb to stash LL addresses").
>>> In order to avoid GRO issue, on packet reception, the IPoIB driver
>>> stash into the skb a dummy pseudo header, so that the received
>>> packets have actually a hard header matching the declared length.
>>> Also the connected mode maximum mtu is reduced by 16 bytes to
>>> cope with the increased hard header len.
>>>
>>> After this commit, IPoIB performances are back to pre-regression
>>> value.
>>>
>>> Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
>>> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>>
>> Not providing an accurate hard_header_len causes many problems.
>>
>> In fact we recently fixed the mlxsw driver to stop doing this.
>>
>
> Sure, but there are too many users of the cb struct, and whatever
> problems you are saying there are by lying about the hard header len are
> dwarfed by the problems caused by the inability to store the ll address
> anywhere between hard_header and send time.
IB wants to pass addressing information between layers, it needs to
find a safe way to do that. The currently propsoed patch does not
meet this criteria.
Pushing metadata before the head of the SKB data pointer is illegal,
as the layers in between might want to push protocol headers, mirror
the packet to another interface, etc.
So this "metadata in SKB data" approach is buggy too.
^ permalink raw reply
* Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header
From: Paolo Abeni @ 2016-10-13 15:17 UTC (permalink / raw)
To: David Miller; +Cc: linux-rdma, dledford, sean.hefty, hal.rosenstock, netdev
In-Reply-To: <20161013.102432.1450901395774429343.davem@davemloft.net>
On Thu, 2016-10-13 at 10:24 -0400, David Miller wrote:
> From: Paolo Abeni <pabeni@redhat.com>
> Date: Tue, 11 Oct 2016 19:15:44 +0200
>
> > After the commit 9207f9d45b0a ("net: preserve IP control block
> > during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
> > That destroy the IPoIB address information cached there,
> > causing a severe performance regression, as better described here:
> >
> > http://marc.info/?l=linux-kernel&m=146787279825501&w=2
> >
> > This change moves the data cached by the IPoIB driver from the
> > skb control lock into the IPoIB hard header, as done before
> > the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
> > and use skb->cb to stash LL addresses").
> > In order to avoid GRO issue, on packet reception, the IPoIB driver
> > stash into the skb a dummy pseudo header, so that the received
> > packets have actually a hard header matching the declared length.
> > Also the connected mode maximum mtu is reduced by 16 bytes to
> > cope with the increased hard header len.
> >
> > After this commit, IPoIB performances are back to pre-regression
> > value.
> >
> > Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>
> Not providing an accurate hard_header_len causes many problems.
>
> In fact we recently fixed the mlxsw driver to stop doing this.
AFAICS the mlxsw did a different thing, adding an additional header in
the xmit function and pushing packets in the network stack with a mac
length different from the declared hard header length
The hard header specified by the IPoIB driver is build in the create()
header_ops and its length matches the mac header length of the packets
pushed into the network stack by such driver. GRO works correctly on top
of that. From the networking stack PoV the hard_header_len should be
'accurate'.
Can you please give more details on the problem that may arise from
this ?
thank you,
Paolo
^ permalink raw reply
* Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header
From: Doug Ledford @ 2016-10-13 15:20 UTC (permalink / raw)
To: David Miller
Cc: pabeni-H+wXaHxf7aLQT0dZR+AlfA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161013.104314.1842951254979604965.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2951 bytes --]
On 10/13/2016 10:43 AM, David Miller wrote:
> From: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date: Thu, 13 Oct 2016 10:35:35 -0400
>
>> On 10/13/2016 10:24 AM, David Miller wrote:
>>> From: Paolo Abeni <pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> Date: Tue, 11 Oct 2016 19:15:44 +0200
>>>
>>>> After the commit 9207f9d45b0a ("net: preserve IP control block
>>>> during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
>>>> That destroy the IPoIB address information cached there,
>>>> causing a severe performance regression, as better described here:
>>>>
>>>> http://marc.info/?l=linux-kernel&m=146787279825501&w=2
>>>>
>>>> This change moves the data cached by the IPoIB driver from the
>>>> skb control lock into the IPoIB hard header, as done before
>>>> the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
>>>> and use skb->cb to stash LL addresses").
>>>> In order to avoid GRO issue, on packet reception, the IPoIB driver
>>>> stash into the skb a dummy pseudo header, so that the received
>>>> packets have actually a hard header matching the declared length.
>>>> Also the connected mode maximum mtu is reduced by 16 bytes to
>>>> cope with the increased hard header len.
>>>>
>>>> After this commit, IPoIB performances are back to pre-regression
>>>> value.
>>>>
>>>> Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
>>>> Signed-off-by: Paolo Abeni <pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>
>>> Not providing an accurate hard_header_len causes many problems.
>>>
>>> In fact we recently fixed the mlxsw driver to stop doing this.
>>>
>>
>> Sure, but there are too many users of the cb struct, and whatever
>> problems you are saying there are by lying about the hard header len are
>> dwarfed by the problems caused by the inability to store the ll address
>> anywhere between hard_header and send time.
>
> IB wants to pass addressing information between layers, it needs to
> find a safe way to do that.
We *had* a safe way to do that. It got broken. What about increasing
the size of skb->cb? Or adding a skb->dgid that is a
u8[INFINIBAND_ALEN]? Or a more generic skb->dest_ll_addr that is sized
to hold the dest address for any link layer?
> Pushing metadata before the head of the SKB data pointer is illegal,
> as the layers in between might want to push protocol headers,
That's a total non-issue for us. There are no headers that protocols
can add before ours.
> mirror
> the packet to another interface
Doesn't that then mean that the headers specific to this interface
should be stripped before the mirror? If so, I believe the way Paolo
did this patch, that is what will be done.
>, etc.
>
> So this "metadata in SKB data" approach is buggy too.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header
From: David Miller @ 2016-10-13 15:57 UTC (permalink / raw)
To: dledford; +Cc: pabeni, linux-rdma, sean.hefty, hal.rosenstock, netdev
In-Reply-To: <2eadc083-e2e0-5c6d-fe84-c5851be3e2ec@redhat.com>
From: Doug Ledford <dledford@redhat.com>
Date: Thu, 13 Oct 2016 11:20:59 -0400
> We *had* a safe way to do that. It got broken. What about increasing
> the size of skb->cb? Or adding a skb->dgid that is a
> u8[INFINIBAND_ALEN]? Or a more generic skb->dest_ll_addr that is sized
> to hold the dest address for any link layer?
I understand the situation, and I also believe that making sk_buff any
huger than it already is happens to be a non-starter.
>> Pushing metadata before the head of the SKB data pointer is illegal,
>> as the layers in between might want to push protocol headers,
>
> That's a total non-issue for us. There are no headers that protocols
> can add before ours.
Ok, if that's the case, and based upon Paolo's response to me it appears
to be, I guess this is OK for now.
Paolo please resubmit your patch, thanks.
^ permalink raw reply
* [PATCH v3] IB/ipoib: move back IB LL address into the hard header
From: Paolo Abeni @ 2016-10-13 16:26 UTC (permalink / raw)
To: linux-rdma
Cc: Doug Ledford, Sean Hefty, Hal Rosenstock, Jason Gunthorpe, netdev,
David Miller
After the commit 9207f9d45b0a ("net: preserve IP control block
during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
That destroy the IPoIB address information cached there,
causing a severe performance regression, as better described here:
http://marc.info/?l=linux-kernel&m=146787279825501&w=2
This change moves the data cached by the IPoIB driver from the
skb control lock into the IPoIB hard header, as done before
the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
and use skb->cb to stash LL addresses").
In order to avoid GRO issue, on packet reception, the IPoIB driver
stash into the skb a dummy pseudo header, so that the received
packets have actually a hard header matching the declared length.
To avoid changing the connected mode maximum mtu, the allocated
head buffer size is increased by the pseudo header length.
After this commit, IPoIB performances are back to pre-regression
value.
v2 -> v3: rebased
v1 -> v2: avoid changing the max mtu, increasing the head buf size
Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
drivers/infiniband/ulp/ipoib/ipoib.h | 20 +++++++---
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 15 +++----
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 12 +++---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 54 ++++++++++++++++----------
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 6 ++-
5 files changed, 64 insertions(+), 43 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h b/drivers/infiniband/ulp/ipoib/ipoib.h
index 7b8d2d9..da12717 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -63,6 +63,8 @@ enum ipoib_flush_level {
enum {
IPOIB_ENCAP_LEN = 4,
+ IPOIB_PSEUDO_LEN = 20,
+ IPOIB_HARD_LEN = IPOIB_ENCAP_LEN + IPOIB_PSEUDO_LEN,
IPOIB_UD_HEAD_SIZE = IB_GRH_BYTES + IPOIB_ENCAP_LEN,
IPOIB_UD_RX_SG = 2, /* max buffer needed for 4K mtu */
@@ -134,15 +136,21 @@ struct ipoib_header {
u16 reserved;
};
-struct ipoib_cb {
- struct qdisc_skb_cb qdisc_cb;
- u8 hwaddr[INFINIBAND_ALEN];
+struct ipoib_pseudo_header {
+ u8 hwaddr[INFINIBAND_ALEN];
};
-static inline struct ipoib_cb *ipoib_skb_cb(const struct sk_buff *skb)
+static inline void skb_add_pseudo_hdr(struct sk_buff *skb)
{
- BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct ipoib_cb));
- return (struct ipoib_cb *)skb->cb;
+ char *data = skb_push(skb, IPOIB_PSEUDO_LEN);
+
+ /*
+ * only the ipoib header is present now, make room for a dummy
+ * pseudo header and set skb field accordingly
+ */
+ memset(data, 0, IPOIB_PSEUDO_LEN);
+ skb_reset_mac_header(skb);
+ skb_pull(skb, IPOIB_HARD_LEN);
}
/* Used for all multicast joins (broadcast, IPv4 mcast and IPv6 mcast) */
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 4ad297d..339a1ee 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -63,6 +63,8 @@
#define IPOIB_CM_RX_DELAY (3 * 256 * HZ)
#define IPOIB_CM_RX_UPDATE_MASK (0x3)
+#define IPOIB_CM_RX_RESERVE (ALIGN(IPOIB_HARD_LEN, 16) - IPOIB_ENCAP_LEN)
+
static struct ib_qp_attr ipoib_cm_err_attr = {
.qp_state = IB_QPS_ERR
};
@@ -146,15 +148,15 @@ static struct sk_buff *ipoib_cm_alloc_rx_skb(struct net_device *dev,
struct sk_buff *skb;
int i;
- skb = dev_alloc_skb(IPOIB_CM_HEAD_SIZE + 12);
+ skb = dev_alloc_skb(ALIGN(IPOIB_CM_HEAD_SIZE + IPOIB_PSEUDO_LEN, 16));
if (unlikely(!skb))
return NULL;
/*
- * IPoIB adds a 4 byte header. So we need 12 more bytes to align the
+ * IPoIB adds a IPOIB_ENCAP_LEN byte header, this will align the
* IP header to a multiple of 16.
*/
- skb_reserve(skb, 12);
+ skb_reserve(skb, IPOIB_CM_RX_RESERVE);
mapping[0] = ib_dma_map_single(priv->ca, skb->data, IPOIB_CM_HEAD_SIZE,
DMA_FROM_DEVICE);
@@ -624,9 +626,9 @@ void ipoib_cm_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
if (wc->byte_len < IPOIB_CM_COPYBREAK) {
int dlen = wc->byte_len;
- small_skb = dev_alloc_skb(dlen + 12);
+ small_skb = dev_alloc_skb(dlen + IPOIB_CM_RX_RESERVE);
if (small_skb) {
- skb_reserve(small_skb, 12);
+ skb_reserve(small_skb, IPOIB_CM_RX_RESERVE);
ib_dma_sync_single_for_cpu(priv->ca, rx_ring[wr_id].mapping[0],
dlen, DMA_FROM_DEVICE);
skb_copy_from_linear_data(skb, small_skb->data, dlen);
@@ -663,8 +665,7 @@ void ipoib_cm_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
copied:
skb->protocol = ((struct ipoib_header *) skb->data)->proto;
- skb_reset_mac_header(skb);
- skb_pull(skb, IPOIB_ENCAP_LEN);
+ skb_add_pseudo_hdr(skb);
++dev->stats.rx_packets;
dev->stats.rx_bytes += skb->len;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
index be11d5d..830fecb 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -128,16 +128,15 @@ static struct sk_buff *ipoib_alloc_rx_skb(struct net_device *dev, int id)
buf_size = IPOIB_UD_BUF_SIZE(priv->max_ib_mtu);
- skb = dev_alloc_skb(buf_size + IPOIB_ENCAP_LEN);
+ skb = dev_alloc_skb(buf_size + IPOIB_HARD_LEN);
if (unlikely(!skb))
return NULL;
/*
- * IB will leave a 40 byte gap for a GRH and IPoIB adds a 4 byte
- * header. So we need 4 more bytes to get to 48 and align the
- * IP header to a multiple of 16.
+ * the IP header will be at IPOIP_HARD_LEN + IB_GRH_BYTES, that is
+ * 64 bytes aligned
*/
- skb_reserve(skb, 4);
+ skb_reserve(skb, sizeof(struct ipoib_pseudo_header));
mapping = priv->rx_ring[id].mapping;
mapping[0] = ib_dma_map_single(priv->ca, skb->data, buf_size,
@@ -253,8 +252,7 @@ static void ipoib_ib_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
skb_pull(skb, IB_GRH_BYTES);
skb->protocol = ((struct ipoib_header *) skb->data)->proto;
- skb_reset_mac_header(skb);
- skb_pull(skb, IPOIB_ENCAP_LEN);
+ skb_add_pseudo_hdr(skb);
++dev->stats.rx_packets;
dev->stats.rx_bytes += skb->len;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 5636fc3..b58d9dc 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -925,9 +925,12 @@ static void neigh_add_path(struct sk_buff *skb, u8 *daddr,
ipoib_neigh_free(neigh);
goto err_drop;
}
- if (skb_queue_len(&neigh->queue) < IPOIB_MAX_PATH_REC_QUEUE)
+ if (skb_queue_len(&neigh->queue) <
+ IPOIB_MAX_PATH_REC_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, IPOIB_PSEUDO_LEN);
__skb_queue_tail(&neigh->queue, skb);
- else {
+ } else {
ipoib_warn(priv, "queue length limit %d. Packet drop.\n",
skb_queue_len(&neigh->queue));
goto err_drop;
@@ -964,7 +967,7 @@ static void neigh_add_path(struct sk_buff *skb, u8 *daddr,
}
static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev,
- struct ipoib_cb *cb)
+ struct ipoib_pseudo_header *phdr)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_path *path;
@@ -972,16 +975,18 @@ static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev,
spin_lock_irqsave(&priv->lock, flags);
- path = __path_find(dev, cb->hwaddr + 4);
+ path = __path_find(dev, phdr->hwaddr + 4);
if (!path || !path->valid) {
int new_path = 0;
if (!path) {
- path = path_rec_create(dev, cb->hwaddr + 4);
+ path = path_rec_create(dev, phdr->hwaddr + 4);
new_path = 1;
}
if (path) {
if (skb_queue_len(&path->queue) < IPOIB_MAX_PATH_REC_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, IPOIB_PSEUDO_LEN);
__skb_queue_tail(&path->queue, skb);
} else {
++dev->stats.tx_dropped;
@@ -1009,10 +1014,12 @@ static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev,
be16_to_cpu(path->pathrec.dlid));
spin_unlock_irqrestore(&priv->lock, flags);
- ipoib_send(dev, skb, path->ah, IPOIB_QPN(cb->hwaddr));
+ ipoib_send(dev, skb, path->ah, IPOIB_QPN(phdr->hwaddr));
return;
} else if ((path->query || !path_rec_start(dev, path)) &&
skb_queue_len(&path->queue) < IPOIB_MAX_PATH_REC_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, IPOIB_PSEUDO_LEN);
__skb_queue_tail(&path->queue, skb);
} else {
++dev->stats.tx_dropped;
@@ -1026,13 +1033,15 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_neigh *neigh;
- struct ipoib_cb *cb = ipoib_skb_cb(skb);
+ struct ipoib_pseudo_header *phdr;
struct ipoib_header *header;
unsigned long flags;
+ phdr = (struct ipoib_pseudo_header *) skb->data;
+ skb_pull(skb, sizeof(*phdr));
header = (struct ipoib_header *) skb->data;
- if (unlikely(cb->hwaddr[4] == 0xff)) {
+ if (unlikely(phdr->hwaddr[4] == 0xff)) {
/* multicast, arrange "if" according to probability */
if ((header->proto != htons(ETH_P_IP)) &&
(header->proto != htons(ETH_P_IPV6)) &&
@@ -1045,13 +1054,13 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_OK;
}
/* Add in the P_Key for multicast*/
- cb->hwaddr[8] = (priv->pkey >> 8) & 0xff;
- cb->hwaddr[9] = priv->pkey & 0xff;
+ phdr->hwaddr[8] = (priv->pkey >> 8) & 0xff;
+ phdr->hwaddr[9] = priv->pkey & 0xff;
- neigh = ipoib_neigh_get(dev, cb->hwaddr);
+ neigh = ipoib_neigh_get(dev, phdr->hwaddr);
if (likely(neigh))
goto send_using_neigh;
- ipoib_mcast_send(dev, cb->hwaddr, skb);
+ ipoib_mcast_send(dev, phdr->hwaddr, skb);
return NETDEV_TX_OK;
}
@@ -1060,16 +1069,16 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
case htons(ETH_P_IP):
case htons(ETH_P_IPV6):
case htons(ETH_P_TIPC):
- neigh = ipoib_neigh_get(dev, cb->hwaddr);
+ neigh = ipoib_neigh_get(dev, phdr->hwaddr);
if (unlikely(!neigh)) {
- neigh_add_path(skb, cb->hwaddr, dev);
+ neigh_add_path(skb, phdr->hwaddr, dev);
return NETDEV_TX_OK;
}
break;
case htons(ETH_P_ARP):
case htons(ETH_P_RARP):
/* for unicast ARP and RARP should always perform path find */
- unicast_arp_send(skb, dev, cb);
+ unicast_arp_send(skb, dev, phdr);
return NETDEV_TX_OK;
default:
/* ethertype not supported by IPoIB */
@@ -1086,11 +1095,13 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
goto unref;
}
} else if (neigh->ah) {
- ipoib_send(dev, skb, neigh->ah, IPOIB_QPN(cb->hwaddr));
+ ipoib_send(dev, skb, neigh->ah, IPOIB_QPN(phdr->hwaddr));
goto unref;
}
if (skb_queue_len(&neigh->queue) < IPOIB_MAX_PATH_REC_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, sizeof(*phdr));
spin_lock_irqsave(&priv->lock, flags);
__skb_queue_tail(&neigh->queue, skb);
spin_unlock_irqrestore(&priv->lock, flags);
@@ -1122,8 +1133,8 @@ static int ipoib_hard_header(struct sk_buff *skb,
unsigned short type,
const void *daddr, const void *saddr, unsigned len)
{
+ struct ipoib_pseudo_header *phdr;
struct ipoib_header *header;
- struct ipoib_cb *cb = ipoib_skb_cb(skb);
header = (struct ipoib_header *) skb_push(skb, sizeof *header);
@@ -1132,12 +1143,13 @@ static int ipoib_hard_header(struct sk_buff *skb,
/*
* we don't rely on dst_entry structure, always stuff the
- * destination address into skb->cb so we can figure out where
+ * destination address into skb hard header so we can figure out where
* to send the packet later.
*/
- memcpy(cb->hwaddr, daddr, INFINIBAND_ALEN);
+ phdr = (struct ipoib_pseudo_header *) skb_push(skb, sizeof(*phdr));
+ memcpy(phdr->hwaddr, daddr, INFINIBAND_ALEN);
- return sizeof *header;
+ return IPOIB_HARD_LEN;
}
static void ipoib_set_mcast_list(struct net_device *dev)
@@ -1759,7 +1771,7 @@ void ipoib_setup(struct net_device *dev)
dev->flags |= IFF_BROADCAST | IFF_MULTICAST;
- dev->hard_header_len = IPOIB_ENCAP_LEN;
+ dev->hard_header_len = IPOIB_HARD_LEN;
dev->addr_len = INFINIBAND_ALEN;
dev->type = ARPHRD_INFINIBAND;
dev->tx_queue_len = ipoib_sendq_size * 2;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index d3394b6..1909dd2 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -796,9 +796,11 @@ void ipoib_mcast_send(struct net_device *dev, u8 *daddr, struct sk_buff *skb)
__ipoib_mcast_add(dev, mcast);
list_add_tail(&mcast->list, &priv->multicast_list);
}
- if (skb_queue_len(&mcast->pkt_queue) < IPOIB_MAX_MCAST_QUEUE)
+ if (skb_queue_len(&mcast->pkt_queue) < IPOIB_MAX_MCAST_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, sizeof(struct ipoib_pseudo_header));
skb_queue_tail(&mcast->pkt_queue, skb);
- else {
+ } else {
++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
}
--
1.8.3.1
^ permalink raw reply related
* Re: Introduction of libqedr to the Consolidated Userspace RDMA Library Repo
From: Jason Gunthorpe @ 2016-10-13 16:29 UTC (permalink / raw)
To: Amrani, Ram
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Elior, Ariel,
Kalderon, Michal, Borundia, Rajesh,
dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
In-Reply-To: <SN1PR07MB22074FE9B280DDDCE439FBA9F8DC0-mikhvbZlbf8TSoR2DauN2+FPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
On Thu, Oct 13, 2016 at 02:37:24PM +0000, Amrani, Ram wrote:
> > >You will want to look at the various patches I've prepared and ensure
> > >you cover off the basic cleanups that have already been done, and that
> > >your code compiles warning-free on FC24.
>
> By cleanups, do you mean to make sure the code compiles warning-free under
> the various flags mentioned throughout the git log (-Wempty-body and etc.),
Yes, Travis will enforce this.
> or are there other kinds of cleanups that I'm missing?
Yes, many of the drivers copied the same stuff that is now gone. Here
is a sampling
https://github.com/linux-rdma/rdma-core/commit/1df0888f6a736e1612ce8b054d6c17651ebd003f
https://github.com/linux-rdma/rdma-core/commit/6771a2051ea5efd30e142866f722d2dae6f565a7
https://github.com/linux-rdma/rdma-core/commit/f29b3285f82815da3abdfea5be5c4f2d1ca92743
https://github.com/linux-rdma/rdma-core/commit/9358a8a5484d1caa0c7ad1826e07d2105f58cc4e
https://github.com/linux-rdma/rdma-core/commit/c5c7e32796b19c3707620a3d2f6b32d00d2fbc3c
> > >Once you feel everything is ready then post it to the mailing list and
> > >send a pull request. For the mailing list you can just split the
> > >patches by file..
>
> As we don't have a publically accessed server I cannot do this at
> the moment (I'm checking how we can set one up). Is it OK if I send
> you the update as a series of patches?
You don't need a server, just a personal github account.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH rdma-next 00/10] Hardware tag matching support
From: Hefty, Sean @ 2016-10-13 17:02 UTC (permalink / raw)
To: Doug Ledford, Leon Romanovsky
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <6259953b-27fe-77c9-ea90-af744f188671-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> I doubt they have, but they change the kernel to user library API. I'm
> not so worried about that since it's entirely under our control. It's
> the user library to application API that I would be more concerned
> with.
I thought there was an agreement that since verbs implies a hardware implementation, then all kernel to user ABI changes to verbs would go through some external organization, such as the OFVWG, for discussion and approval. Has that changed?
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH rdma-next 00/10] Hardware tag matching support
From: Christoph Hellwig @ 2016-10-13 17:06 UTC (permalink / raw)
To: Hefty, Sean
Cc: Doug Ledford, Leon Romanovsky,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373AB095429-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Thu, Oct 13, 2016 at 05:02:13PM +0000, Hefty, Sean wrote:
> > I doubt they have, but they change the kernel to user library API. I'm
> > not so worried about that since it's entirely under our control. It's
> > the user library to application API that I would be more concerned
> > with.
>
> I thought there was an agreement that since verbs implies a hardware implementation, then all kernel to user ABI changes to verbs would go through some external organization, such as the OFVWG, for discussion and approval. Has that changed?
What makes OFVWG more qualified to review an ABI than linux-rdma?
That beeing said a review by an independent third party in addition to
the vensors (intentional plural here!) is important, but I think we can
handle that just fine.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* trivial sparse fixes for rdma-core
From: Christoph Hellwig @ 2016-10-13 17:51 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
This is the low hanging fruit in terms of reducing sparse noise before
looking into endianess and iomem annotations.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 01/32] libibumad: include umad_str.h in umad_str.c
From: Christoph Hellwig @ 2016-10-13 17:51 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476381095-20041-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
So that we have the prototypes available in the implementation file
and do get proper type checking for them.
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
libibumad/umad_str.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libibumad/umad_str.c b/libibumad/umad_str.c
index 79d51af..d4832e1 100644
--- a/libibumad/umad_str.c
+++ b/libibumad/umad_str.c
@@ -40,6 +40,7 @@
#include <infiniband/umad_sm.h>
#include <infiniband/umad_sa.h>
#include <infiniband/umad_cm.h>
+#include "umad_str.h"
const char * umad_class_str(uint8_t mgmt_class)
{
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 02/32] libibumad: create sysfs.h instead of using extern declarations in umad.c
From: Christoph Hellwig @ 2016-10-13 17:51 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476381095-20041-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
So that we have the prototypes available in the implementation file
and do get proper type checking for them.
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
libibumad/sysfs.c | 1 +
libibumad/sysfs.h | 10 ++++++++++
libibumad/umad.c | 7 +------
3 files changed, 12 insertions(+), 6 deletions(-)
create mode 100644 libibumad/sysfs.h
diff --git a/libibumad/sysfs.c b/libibumad/sysfs.c
index 011e411..83f89b4 100644
--- a/libibumad/sysfs.c
+++ b/libibumad/sysfs.c
@@ -44,6 +44,7 @@
#include <byteswap.h>
#include <netinet/in.h>
#include <infiniband/arch.h>
+#include "sysfs.h"
static int ret_code(void)
{
diff --git a/libibumad/sysfs.h b/libibumad/sysfs.h
new file mode 100644
index 0000000..7f8cbfe
--- /dev/null
+++ b/libibumad/sysfs.h
@@ -0,0 +1,10 @@
+#ifndef _UMAD_SYSFS_H
+#define _UMAD_SYSFS_H
+
+extern int sys_read_string(const char *dir_name, const char *file_name, char *str, int len);
+extern int sys_read_guid(const char *dir_name, const char *file_name, uint64_t * net_guid);
+extern int sys_read_gid(const char *dir_name, const char *file_name, uint8_t * gid);
+extern int sys_read_uint64(const char *dir_name, const char *file_name, uint64_t * u);
+extern int sys_read_uint(const char *dir_name, const char *file_name, unsigned *u);
+
+#endif /* _UMAD_SYSFS_H */
diff --git a/libibumad/umad.c b/libibumad/umad.c
index 0c969f1..8860b99 100644
--- a/libibumad/umad.c
+++ b/libibumad/umad.c
@@ -53,6 +53,7 @@
#define IB_OPENIB_OUI (0x001405)
#include <valgrind/memcheck.h>
+#include "sysfs.h"
typedef struct ib_user_mad_reg_req {
uint32_t id;
@@ -77,12 +78,6 @@ struct ib_user_mad_reg_req2 {
uint8_t reserved[3];
};
-extern int sys_read_string(const char *dir_name, const char *file_name, char *str, int len);
-extern int sys_read_guid(const char *dir_name, const char *file_name, uint64_t * net_guid);
-extern int sys_read_gid(const char *dir_name, const char *file_name, uint8_t * gid);
-extern int sys_read_uint64(const char *dir_name, const char *file_name, uint64_t * u);
-extern int sys_read_uint(const char *dir_name, const char *file_name, unsigned *u);
-
#define IBWARN(fmt, args...) fprintf(stderr, "ibwarn: [%d] %s: " fmt "\n", getpid(), __func__, ## args)
#define TRACE if (umaddebug) IBWARN
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 03/32] libibumad: use NULL instead of 0 for NULL pointers
From: Christoph Hellwig @ 2016-10-13 17:51 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476381095-20041-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
libibumad/sysfs.c | 8 ++++----
libibumad/umad.c | 17 +++++++++--------
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/libibumad/sysfs.c b/libibumad/sysfs.c
index 83f89b4..730374d 100644
--- a/libibumad/sysfs.c
+++ b/libibumad/sysfs.c
@@ -95,7 +95,7 @@ int sys_read_guid(const char *dir_name, const char *file_name, uint64_t * net_gu
for (s = buf, i = 0; i < 4; i++) {
if (!(str = strsep(&s, ": \t\n")))
return -EINVAL;
- guid = (guid << 16) | (strtoul(str, 0, 16) & 0xffff);
+ guid = (guid << 16) | (strtoul(str, NULL, 16) & 0xffff);
}
*net_guid = htonll(guid);
@@ -115,7 +115,7 @@ int sys_read_gid(const char *dir_name, const char *file_name, uint8_t * gid)
for (s = buf, i = 0; i < 8; i++) {
if (!(str = strsep(&s, ": \t\n")))
return -EINVAL;
- ugid[i] = htons(strtoul(str, 0, 16) & 0xffff);
+ ugid[i] = htons(strtoul(str, NULL, 16) & 0xffff);
}
return 0;
@@ -129,7 +129,7 @@ int sys_read_uint64(const char *dir_name, const char *file_name, uint64_t * u)
if ((r = sys_read_string(dir_name, file_name, buf, sizeof(buf))) < 0)
return r;
- *u = strtoull(buf, 0, 0);
+ *u = strtoull(buf, NULL, 0);
return 0;
}
@@ -142,7 +142,7 @@ int sys_read_uint(const char *dir_name, const char *file_name, unsigned *u)
if ((r = sys_read_string(dir_name, file_name, buf, sizeof(buf))) < 0)
return r;
- *u = strtoul(buf, 0, 0);
+ *u = strtoul(buf, NULL, 0);
return 0;
}
diff --git a/libibumad/umad.c b/libibumad/umad.c
index 8860b99..c1b7338 100644
--- a/libibumad/umad.c
+++ b/libibumad/umad.c
@@ -215,7 +215,7 @@ static int release_ca(umad_ca_t * ca)
continue;
release_port(ca->ports[i]);
free(ca->ports[i]);
- ca->ports[i] = 0;
+ ca->ports[i] = NULL;
}
return 0;
}
@@ -320,13 +320,13 @@ static const char *resolve_ca_name(const char *ca_name, int *best_port)
if (ca_name) {
if (resolve_ca_port(ca_name, best_port) < 0)
- return 0;
+ return NULL;
return ca_name;
}
/* Get the list of CA names */
if ((n = umad_get_cas_names((void *)names, UMAD_MAX_DEVICES)) < 0)
- return 0;
+ return NULL;
/* Find the first existing CA with an active port */
for (caidx = 0; caidx < n; caidx++) {
@@ -354,7 +354,8 @@ static const char *resolve_ca_name(const char *ca_name, int *best_port)
}
DEBUG("phys found %d on %s port %d",
- phys_found, phys_found >= 0 ? names[phys_found] : 0, port_found);
+ phys_found, phys_found >= 0 ? names[phys_found] : NULL,
+ port_found);
if (phys_found >= 0) {
if (best_port)
*best_port = port_found;
@@ -404,7 +405,7 @@ static int get_ca(const char *ca_name, umad_ca_t * ca)
if (!(dir = opendir(dir_name)))
return -ENOENT;
- if ((r = scandir(dir_name, &namelist, 0, alphasort)) < 0) {
+ if ((r = scandir(dir_name, &namelist, NULL, alphasort)) < 0) {
ret = errno < 0 ? errno : -EIO;
goto error;
}
@@ -544,7 +545,7 @@ int umad_get_cas_names(char cas[][UMAD_CA_NAME_LEN], int max)
TRACE("max %d", max);
- n = scandir(SYS_INFINIBAND, &namelist, 0, alphasort);
+ n = scandir(SYS_INFINIBAND, &namelist, NULL, alphasort);
if (n > 0) {
for (i = 0; i < n; i++) {
if (strcmp(namelist[i]->d_name, ".") &&
@@ -573,7 +574,7 @@ int umad_get_ca_portguids(const char *ca_name, uint64_t * portguids, int max)
int ports = 0, i;
TRACE("ca name %s max port guids %d", ca_name, max);
- if (!(ca_name = resolve_ca_name(ca_name, 0)))
+ if (!(ca_name = resolve_ca_name(ca_name, NULL)))
return -ENODEV;
if (umad_get_ca(ca_name, &ca) < 0)
@@ -650,7 +651,7 @@ int umad_get_ca(const char *ca_name, umad_ca_t * ca)
int r;
TRACE("ca_name %s", ca_name);
- if (!(ca_name = resolve_ca_name(ca_name, 0)))
+ if (!(ca_name = resolve_ca_name(ca_name, NULL)))
return -ENODEV;
if (find_cached_ca(ca_name, ca) > 0)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 04/32] libibumad: mark symbols as static where possible
From: Christoph Hellwig @ 2016-10-13 17:51 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476381095-20041-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
libibumad/tests/umad_reg2_compat.c | 10 +++++-----
libibumad/tests/umad_register2.c | 12 ++++++------
libibumad/umad.c | 2 +-
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/libibumad/tests/umad_reg2_compat.c b/libibumad/tests/umad_reg2_compat.c
index 264882c..9224372 100644
--- a/libibumad/tests/umad_reg2_compat.c
+++ b/libibumad/tests/umad_reg2_compat.c
@@ -42,7 +42,7 @@
#define UNLIKELY_MGMT_CLASS 0x2F
#define UNLIKELY_RMPP_MGMT_CLASS 0x4F
-int test_failures = 0;
+static int test_failures = 0;
/** =========================================================================
* Stolen from OpenSM's register
@@ -69,7 +69,7 @@ static void set_bit64(int b, uint64_t *buf)
*addr |= mask;
}
-void dump_reg_attr(struct umad_reg_attr *reg_attr)
+static void dump_reg_attr(struct umad_reg_attr *reg_attr)
{
printf("\nmgmt_class %u\n"
"mgmt_class_version %u\n"
@@ -85,7 +85,7 @@ void dump_reg_attr(struct umad_reg_attr *reg_attr)
reg_attr->rmpp_version);
}
-int open_test_device(void)
+static int open_test_device(void)
{
int fd = umad_open_port(NULL, 0);
if (fd < 0) {
@@ -96,7 +96,7 @@ int open_test_device(void)
return fd;
}
-void test_register(void)
+static void test_register(void)
{
int agent_id;
long method_mask[16 / sizeof(long)];
@@ -147,7 +147,7 @@ void test_register(void)
}
-void test_fall_back(void)
+static void test_fall_back(void)
{
int rc = 0;
struct umad_reg_attr reg_attr;
diff --git a/libibumad/tests/umad_register2.c b/libibumad/tests/umad_register2.c
index 7a9b655..477bd29 100644
--- a/libibumad/tests/umad_register2.c
+++ b/libibumad/tests/umad_register2.c
@@ -57,9 +57,9 @@ struct ib_user_mad_reg_req2 {
uint8_t reserved[3];
};
-int test_failures = 0;
+static int test_failures = 0;
-void dump_reg_attr(struct umad_reg_attr *reg_attr)
+static void dump_reg_attr(struct umad_reg_attr *reg_attr)
{
printf("\nmgmt_class %u\n"
"mgmt_class_version %u\n"
@@ -75,7 +75,7 @@ void dump_reg_attr(struct umad_reg_attr *reg_attr)
reg_attr->rmpp_version);
}
-int open_test_device(void)
+static int open_test_device(void)
{
int fd = umad_open_port(NULL, 0);
if (fd < 0) {
@@ -86,7 +86,7 @@ int open_test_device(void)
return fd;
}
-void test_fail(void)
+static void test_fail(void)
{
int rc = 0;
struct umad_reg_attr reg_attr;
@@ -194,7 +194,7 @@ out:
printf("\n *****\nEnd invalid tests\n");
}
-void test_oui(void)
+static void test_oui(void)
{
int rc = 0;
struct umad_reg_attr reg_attr;
@@ -251,7 +251,7 @@ out:
printf("\n End valid oui tests\n *****\n");
}
-void check_register2_support(void)
+static void check_register2_support(void)
{
struct ib_user_mad_reg_req2 req;
int fd;
diff --git a/libibumad/umad.c b/libibumad/umad.c
index c1b7338..1ac2948 100644
--- a/libibumad/umad.c
+++ b/libibumad/umad.c
@@ -83,7 +83,7 @@ struct ib_user_mad_reg_req2 {
#define TRACE if (umaddebug) IBWARN
#define DEBUG if (umaddebug) IBWARN
-int umaddebug = 0;
+static int umaddebug = 0;
#define UMAD_DEV_FILE_SZ 256
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 05/32] srp_daemon: use NULL instead of 0 for NULL pointers
From: Christoph Hellwig @ 2016-10-13 17:51 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476381095-20041-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
srp_daemon/srp_daemon.c | 34 +++++++++++++++++-----------------
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/srp_daemon/srp_daemon.c b/srp_daemon/srp_daemon.c
index f16674d..2317508 100644
--- a/srp_daemon/srp_daemon.c
+++ b/srp_daemon/srp_daemon.c
@@ -189,7 +189,7 @@ int srpd_sys_read_gid(char *dir_name, char *file_name, uint8_t *gid)
for (s = buf, i = 0 ; i < 8; i++) {
if (!(str = strsep(&s, ": \t\n")))
return -EINVAL;
- ugid[i] = htons(strtoul(str, 0, 16) & 0xffff);
+ ugid[i] = htons(strtoul(str, NULL, 16) & 0xffff);
}
return 0;
@@ -203,7 +203,7 @@ int srpd_sys_read_uint64(char *dir_name, char *file_name, uint64_t *u)
if ((r = srpd_sys_read_string(dir_name, file_name, buf, sizeof(buf))) < 0)
return r;
- *u = strtoull(buf, 0, 0);
+ *u = strtoull(buf, NULL, 0);
return 0;
}
@@ -356,36 +356,36 @@ int is_enabled_by_rules_file(struct target_details *target)
do {
rule++;
if (conf->rules[rule].id_ext[0] != '\0' &&
- strtoull(target->id_ext, 0, 16) !=
- strtoull(conf->rules[rule].id_ext, 0, 16))
+ strtoull(target->id_ext, NULL, 16) !=
+ strtoull(conf->rules[rule].id_ext, NULL, 16))
continue;
if (conf->rules[rule].ioc_guid[0] != '\0' &&
ntohll(target->ioc_prof.guid) !=
- strtoull(conf->rules[rule].ioc_guid, 0, 16))
+ strtoull(conf->rules[rule].ioc_guid, NULL, 16))
continue;
if (conf->rules[rule].dgid[0] != '\0') {
char tmp = conf->rules[rule].dgid[16];
conf->rules[rule].dgid[16] = '\0';
- if (strtoull(conf->rules[rule].dgid, 0, 16) !=
+ if (strtoull(conf->rules[rule].dgid, NULL, 16) !=
target->subnet_prefix) {
conf->rules[rule].dgid[16] = tmp;
continue;
}
conf->rules[rule].dgid[16] = tmp;
- if (strtoull(&conf->rules[rule].dgid[16], 0, 16) !=
+ if (strtoull(&conf->rules[rule].dgid[16], NULL, 16) !=
target->h_guid)
continue;
}
if (conf->rules[rule].service_id[0] != '\0' &&
- strtoull(conf->rules[rule].service_id, 0, 16) !=
+ strtoull(conf->rules[rule].service_id, NULL, 16) !=
target->h_service_id)
continue;
if (conf->rules[rule].pkey[0] != '\0' &&
- (uint16_t)strtoul(conf->rules[rule].pkey, 0, 16) !=
+ (uint16_t)strtoul(conf->rules[rule].pkey, NULL, 16) !=
target->pkey)
continue;
@@ -436,7 +436,7 @@ static int add_non_exist_target(struct target_details *target)
strncpy(subdir_name_ptr, subdir->d_name,
MAX_SCSI_HOST_DIR_NAME_LENGTH - prefix_len);
if (!check_equal_uint64(scsi_host_dir, "id_ext",
- strtoull(target->id_ext, 0, 16)))
+ strtoull(target->id_ext, NULL, 16)))
continue;
if (!check_equal_uint16(scsi_host_dir, "pkey", target->pkey) &&
!config->execute)
@@ -1795,7 +1795,7 @@ static int umad_resources_create(struct umad_resources *umad_res)
umad_res->agent = umad_register(umad_res->portid, SRP_MGMT_CLASS_SA,
SRP_MGMT_CLASS_SA_VERSION,
- SRP_SA_RMPP_VERSION, 0);
+ SRP_SA_RMPP_VERSION, NULL);
if (umad_res->agent < 0) {
pr_err("umad_register failed\n");
return umad_res->agent;
@@ -2064,9 +2064,9 @@ int main(int argc, char *argv[])
memset(&sa, 0, sizeof(sa));
sigemptyset(&sa.sa_mask);
sa.sa_handler = signal_handler;
- sigaction(SIGINT, &sa, 0);
- sigaction(SIGTERM, &sa, 0);
- sigaction(SRP_CATAS_ERR, &sa, 0);
+ sigaction(SIGINT, &sa, NULL);
+ sigaction(SIGTERM, &sa, NULL);
+ sigaction(SRP_CATAS_ERR, &sa, NULL);
if (strcmp(argv[0] + max_t(int, 0, strlen(argv[0]) - strlen("ibsrpdm")),
"ibsrpdm") == 0) {
@@ -2268,9 +2268,9 @@ close_log:
closelog();
restore_sig:
sa.sa_handler = SIG_DFL;
- sigaction(SIGINT, &sa, 0);
- sigaction(SIGTERM, &sa, 0);
- sigaction(SRP_CATAS_ERR, &sa, 0);
+ sigaction(SIGINT, &sa, NULL);
+ sigaction(SIGTERM, &sa, NULL);
+ sigaction(SRP_CATAS_ERR, &sa, NULL);
close_pipe:
close(wakeup_pipe[1]);
close(wakeup_pipe[0]);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 06/32] srp_daemon: mark symbols as static where possible
From: Christoph Hellwig @ 2016-10-13 17:51 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476381095-20041-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
srp_daemon/srp_daemon.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/srp_daemon/srp_daemon.c b/srp_daemon/srp_daemon.c
index 2317508..f0f05cf 100644
--- a/srp_daemon/srp_daemon.c
+++ b/srp_daemon/srp_daemon.c
@@ -151,7 +151,7 @@ static int check_process_uniqueness(struct config_t *conf)
return fd;
}
-int srpd_sys_read_string(const char *dir_name, const char *file_name,
+static int srpd_sys_read_string(const char *dir_name, const char *file_name,
char *str, int max_len)
{
char path[256], *s;
@@ -177,7 +177,7 @@ int srpd_sys_read_string(const char *dir_name, const char *file_name,
return 0;
}
-int srpd_sys_read_gid(char *dir_name, char *file_name, uint8_t *gid)
+static int srpd_sys_read_gid(char *dir_name, char *file_name, uint8_t *gid)
{
char buf[64], *str, *s;
uint16_t *ugid = (uint16_t *)gid;
@@ -195,7 +195,7 @@ int srpd_sys_read_gid(char *dir_name, char *file_name, uint8_t *gid)
return 0;
}
-int srpd_sys_read_uint64(char *dir_name, char *file_name, uint64_t *u)
+static int srpd_sys_read_uint64(char *dir_name, char *file_name, uint64_t *u)
{
char buf[32];
int r;
@@ -257,7 +257,7 @@ check_equal_uint16(char *dir_name, char *attr, uint16_t val)
static int recalc(struct resources *res);
-void pr_cmd(char *target_str, int not_connected)
+static void pr_cmd(char *target_str, int not_connected)
{
int ret;
@@ -343,7 +343,7 @@ static int check_not_equal_int(char *dir_name, char *attr, int value)
return 0;
}
-int is_enabled_by_rules_file(struct target_details *target)
+static int is_enabled_by_rules_file(struct target_details *target)
{
int rule;
struct config_t *conf = config;
@@ -584,7 +584,7 @@ static int add_non_exist_target(struct target_details *target)
return 1;
}
-int send_and_get(int portid, int agent, srp_ib_user_mad_t *out_mad,
+static int send_and_get(int portid, int agent, srp_ib_user_mad_t *out_mad,
srp_ib_user_mad_t *in_mad, int in_mad_size)
{
struct srp_dm_mad *out_dm_mad = (void *) out_mad->hdr.data;
@@ -1804,7 +1804,7 @@ static int umad_resources_create(struct umad_resources *umad_res)
return 0;
}
-void *run_thread_retry_to_connect(void *res_in)
+static void *run_thread_retry_to_connect(void *res_in)
{
struct resources *res = (struct resources *)res_in;
struct target_details *target;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 07/32] srp_daemon: give initialize_sysfs a proper ANSI-C prototype
From: Christoph Hellwig @ 2016-10-13 17:51 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476381095-20041-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
srp_daemon/srp_daemon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/srp_daemon/srp_daemon.c b/srp_daemon/srp_daemon.c
index f0f05cf..6cb22e4 100644
--- a/srp_daemon/srp_daemon.c
+++ b/srp_daemon/srp_daemon.c
@@ -647,7 +647,7 @@ recv:
return -1;
}
-static void initialize_sysfs()
+static void initialize_sysfs(void)
{
char *env;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 08/32] iwpmd: use proper ANSI-C prototypes for functions without arguments
From: Christoph Hellwig @ 2016-10-13 17:51 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476381095-20041-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
iwpmd/iwarp_pm_common.c | 2 +-
iwpmd/iwarp_pm_server.c | 10 +++++-----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/iwpmd/iwarp_pm_common.c b/iwpmd/iwarp_pm_common.c
index 3a885d8..aa6b4a0 100644
--- a/iwpmd/iwarp_pm_common.c
+++ b/iwpmd/iwarp_pm_common.c
@@ -212,7 +212,7 @@ create_socket_v6_exit:
/**
* create_netlink_socket - Create netlink socket for the iwarp port mapper
*/
-int create_netlink_socket()
+int create_netlink_socket(void)
{
sockaddr_union bind_addr;
struct sockaddr_nl *bind_nl;
diff --git a/iwpmd/iwarp_pm_server.c b/iwpmd/iwarp_pm_server.c
index deed3e7..89d3ee5 100644
--- a/iwpmd/iwarp_pm_server.c
+++ b/iwpmd/iwarp_pm_server.c
@@ -87,7 +87,7 @@ void iwpm_signal_handler(int signum)
/**
* iwpm_mapping_reqs_handler - Handle mapping requests timeouts and retries
*/
-void *iwpm_mapping_reqs_handler()
+void *iwpm_mapping_reqs_handler(void)
{
iwpm_mapping_request *iwpm_map_req, *next_map_req;
int ret = 0;
@@ -139,7 +139,7 @@ mapping_reqs_handler_exit:
/**
* iwpm_pending_msgs_handler - Handle sending iwarp port mapper wire messages
*/
-void *iwpm_pending_msgs_handler()
+void *iwpm_pending_msgs_handler(void)
{
iwpm_pending_msg *pending_msg;
iwpm_send_msg *send_msg;
@@ -1279,7 +1279,7 @@ static void iwpm_cleanup(void)
/**
* iwarp_port_mapper - Distribute work orders for processing different types of iwpm messages
*/
-static int iwarp_port_mapper()
+static int iwarp_port_mapper(void)
{
fd_set select_fdset; /* read fdset */
struct timeval select_timeout;
@@ -1355,8 +1355,8 @@ iwarp_port_mapper_exit:
/**
* daemonize_iwpm_server - Make iwarp port mapper a daemon process
- */
-static void daemonize_iwpm_server()
+ */
+static void daemonize_iwpm_server(void)
{
pid_t pid, sid;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 09/32] iwpmd: remove the unused check_iwpm_nlattr_tb prototype
From: Christoph Hellwig @ 2016-10-13 17:51 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476381095-20041-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
iwpmd/iwarp_pm.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/iwpmd/iwarp_pm.h b/iwpmd/iwarp_pm.h
index 8b7eeb1..1a2b69a 100644
--- a/iwpmd/iwarp_pm.h
+++ b/iwpmd/iwarp_pm.h
@@ -209,8 +209,6 @@ int create_netlink_socket(void);
void destroy_iwpm_socket(int);
-int check_iwpm_nlattr_tb(struct nlattr * [], int);
-
int parse_iwpm_nlmsg(struct nlmsghdr *, int, struct nla_policy *, struct nlattr * [], const char *);
int parse_iwpm_msg(iwpm_wire_msg *, iwpm_msg_parms *);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox