* Re: [PATCH 0/3] infiniband: IB/hns: Hisilicon RoCE support
From: oulijun @ 2016-03-19 11:13 UTC (permalink / raw)
To: dledford, sean.hefty, hal.rosenstock, davem, jeffrey.t.kirsher,
jiri, ogerlitz, linux-rdma, linux-kernel, netdev, gongyangming,
xiaokun, tangchaofei, haifeng.wei, yisen.zhuang, yankejian,
lisheng011, charles.chenxin, linuxarm
In-Reply-To: <20160312102051.GC11383@leon.nu>
On 2016/3/12 18:20, Leon Romanovsky wrote:
> On Fri, Mar 11, 2016 at 06:37:08PM +0800, Lijun Ou wrote:
>
> 1) It is redundant to write "infiniband" and "IB" in one title to mention
> relevant subsystem, since it is the same.
>
> Please take a look on the other submissions here on the list and use
> similar construction.
>
> 2) Please use version number in the titles [PATCH vXXX]
>
Hi dledford, thanks for reviewing
I have modified it, I will send a new patch at soon
thanks
Lijun Ou
>> The Hisilicon Network Substem(hns) is a long term evolution IP which is
>> supposed to be used in Hisilicon ICT SoC. RoCE is a feature of hns.
>> The driver for Hisilicon RoCE engine is a platform driver.
>> The driver will support mulitple versions of hns. Currently only "v1"
>> for hip06 SOC is supported.
>>
>>
>> Changes v1 -> v2:
>> 1. adjust the formats of roce driver code by the experts reviewing
>> 2. modify the bindings file with roce dts. add the attribute named
>> interrput-names.
>> 3. modify the way of defining port mode in hns_dsaf_main.c
>> 4. move the Kconfig file into the hns directory and send it with roce
>> driver code file together.
>>
>>
>> Lijun Ou (3):
>> infiniband: IB/hns: add Hisilicon RoCE support
>> net: hns: add Hisilicon RoCE support
>> infiniband: IB/hns: add Hisilicon RoCE support with bindings
>>
>
> .
>
^ permalink raw reply
* Re: [PATCH 3/3] infiniband: IB/hns: add Hisilicon RoCE support with bindings
From: oulijun @ 2016-03-19 11:14 UTC (permalink / raw)
To: Sergei Shtylyov, dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
jiri-VPRAkNaXOzVWk0Htik3J/w, ogerlitz-VPRAkNaXOzVWk0Htik3J/w
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
gongyangming-hv44wF8Li93QT0dZR+AlfA,
xiaokun-hv44wF8Li93QT0dZR+AlfA,
tangchaofei-hv44wF8Li93QT0dZR+AlfA,
haifeng.wei-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
lisheng011-hv44wF8Li93QT0dZR+AlfA,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA,
linuxarm-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <56E2CA90.9020401-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On 2016/3/11 21:39, Sergei Shtylyov wrote:
> Hello.
>
> On 3/11/2016 1:37 PM, Lijun Ou wrote:
>
>> This submit add binding file and dts file.
>
> I see no .dts file.
>
>>
>> Signed-off-by: Lijun Ou <oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> Signed-off-by: Wei Hu(Xavier) <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> ---
>> .../bindings/infiniband/hisilicon-hns-roce.txt | 68 ++++++++++++++++++++++
>> 1 file changed, 68 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/infiniband/hisilicon-hns-roce.txt
>>
>> diff --git a/Documentation/devicetree/bindings/infiniband/hisilicon-hns-roce.txt b/Documentation/devicetree/bindings/infiniband/hisilicon-hns-roce.txt
>> new file mode 100644
>> index 0000000..8004641
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/infiniband/hisilicon-hns-roce.txt
>> @@ -0,0 +1,68 @@
>> +HiSilicon RoCE DT description
>> +
>> +HiSilicon RoCE engine is a part of network subsystem.
>> +It works depending on other part of network wubsytem, such as, gmac and
>
> Subsystem.
>
>> +dsa fabric.
>> +
>> +Additional properties are described here:
>> +
>> +Required properties:
>> +- compatible: Should contain "hisilicon,hns-roce-v1".
>> +- reg: Physical base address of the roce driver and
>> +length of memory mapped region.
>> +- eth-handle: phandle, specifies a reference to a node
>> +representing a ethernet device.
>> +- dsaf-handle: phandle, specifies a reference to a node
>> +representing a dsaf device.
>> +- #address-cells: must be 2
>> +- #size-cells: must be 2
>> +Optional properties:
>> +- dma-coherent: Present if DMA operations are coherent.
>> +- interrupt-parent: the interrupt parent of this device.
>> +- interrupts: should contain 32 completion event irq,1 async event irq
>> +and 1 event overflow irq.
>
> The "interrupt-names" prop is strongly desired with some many IRQs.
>
>> +Example:
>> + rocee@0xc4000000 {
>
> The node names should be generic, not implementation specific.
>
> [...]
>
> MBR, Sergei
>
>
> .
>
Hi Sergei Shtylyov , thanks for reviewing
I have modified it, I will send a new patch at soon
thanks
Lijun Ou
--
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 2/3] net: hns: add Hisilicon RoCE support
From: oulijun @ 2016-03-19 11:17 UTC (permalink / raw)
To: Yankejian (Hackim Yim), dledford, sean.hefty, hal.rosenstock,
davem, jeffrey.t.kirsher, jiri, ogerlitz, linux-rdma,
linux-kernel, netdev, gongyangming, xiaokun, tangchaofei,
haifeng.wei, yisen.zhuang, lisheng011, charles.chenxin, linuxarm
In-Reply-To: <20160314064921.GA26456@leon.nu>
On 2016/3/14 14:49, Leon Romanovsky wrote:
> On Mon, Mar 14, 2016 at 09:12:28AM +0800, Yankejian (Hackim Yim) wrote:
>>
>>
>> On 2016/3/12 18:43, Leon Romanovsky wrote:
>>> On Fri, Mar 11, 2016 at 06:37:10PM +0800, Lijun Ou wrote:
>>>> It added hns_dsaf_roce_reset routine for roce driver.
>>>> RoCE is a feature of hns.
>>>> In hip06 SOC, in roce reset process, it's needed to configure
>>>> dsaf channel reset,port and sl map info.
>>>>
>>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>>>> Signed-off-by: Wei Hu(Xavier) <xavier.huwei@huawei.com>
>>>> Signed-off-by: Lisheng <lisheng011@huawei.com>
>>>> ---
>>>> drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 84 ++++++++++++++++++++++
>>>> drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h | 14 ++++
>>>> drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 62 +++++++++++++---
>>>> drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h | 13 ++++
>>>> 4 files changed, 163 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
>>>> index 38fc5be..a0f0d4f 100644
>>>> --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
>>>> +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
>>>> @@ -12,6 +12,7 @@
>>>> #include <linux/init.h>
>>>> #include <linux/interrupt.h>
>>>> #include <linux/netdevice.h>
>>>> +#include <linux/of_platform.h>
>>>> #include <linux/platform_device.h>
>>>> #include <linux/of.h>
>>>> #include <linux/of_address.h>
>>>> @@ -2593,6 +2594,89 @@ static struct platform_driver g_dsaf_driver = {
>>>>
>>>> module_platform_driver(g_dsaf_driver);
>>>>
>>>> +/**
>>>> + * hns_dsaf_roce_reset - reset dsaf and roce
>>>> + * @dsaf_fwnode: Pointer to framework node for the dasf
>>>> + * @val: 0 - request reset , 1 - drop reset
>>>> + * retuen 0 - success , negative --fail
>>>> + */
>>>> +int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, u32 val)
>>>> +{
>>>> + struct dsaf_device *dsaf_dev;
>>>> + struct platform_device *pdev;
>>>> + unsigned int mp;
>>>> + unsigned int sl;
>>>> + unsigned int credit;
>>>> + int i;
>>>> + const u32 port_map[DSAF_ROCE_CREDIT_CHN][DSAF_ROCE_CHAN_MODE] = {
>>>> + {0, 0, 0},
>>>> + {1, 0, 0},
>>>> + {2, 1, 0},
>>>> + {3, 1, 0},
>>>> + {4, 2, 1},
>>>> + {4, 2, 1},
>>>> + {5, 3, 1},
>>>> + {5, 3, 1},
>>>> + };
>>>> + const u32 sl_map[DSAF_ROCE_CREDIT_CHN][DSAF_ROCE_CHAN_MODE] = {
>>>> + {0, 0, 0},
>>>> + {0, 1, 1},
>>>> + {0, 0, 2},
>>>> + {0, 1, 3},
>>>> + {0, 0, 0},
>>>> + {1, 1, 1},
>>>> + {0, 0, 2},
>>>> + {1, 1, 3},
>>>> + };
>>> Do you have a plan to send a version with enums/defines for this
>>> numbers? Especially for _CHAN_MODE.
>>>
>>> .
>>
>> Hi leon,
>>
>> it seems the enums is added in hns_dsaf_main.h, as belows:
>>
>> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
>> index 5fea226..c917b9a 100644
>> --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
>> +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
>> @@ -40,6 +40,16 @@ struct hns_mac_cb;
>> #define DSAF_DUMP_REGS_NUM 504
>> #define DSAF_STATIC_NUM 28
>>
>> +#define DSAF_ROCE_CREDIT_CHN 8
>> +#define DSAF_ROCE_CHAN_MODE 3
>> +
>> +enum dsaf_roce_port_port_mode {
>> + DSAF_ROCE_6PORT_MODE,
>> + DSAF_ROCE_4PORT_MODE,
>> + DSAF_ROCE_2PORT_MODE,
>> + DSAF_ROCE_CHAN_MODE_NUM
>> +};
>> +
>
> These defines are used as an index entry into si_map and port_map arrays
> and seems as not related to the actual data.
>
> I suggest you to take this code back to drawing table, redesign it,
> clean unused functions and defines and resubmit it.
>
> Thanks.
>
Hi Leon Romanovsky
I have redesigned the port_map and sl_map structures. Please refer to the
hns_dsaf_main.c and hns_dsaf_main.h.
thanks
Lijun Ou
>>
>> MBR, Kejian
>>
>>
>>
>>
>>
>>
>> --
>> 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
>
> .
>
^ permalink raw reply
* Re: [PATCH 3/4] infiniband: hns: add Hisilicon RoCE support(driver code)
From: oulijun @ 2016-03-19 11:28 UTC (permalink / raw)
To: Parav Pandit
Cc: Wei Hu(Xavier), Doug Ledford, Hefty, Sean, Hal Rosenstock,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
jiri-VPRAkNaXOzVWk0Htik3J/w, Or Gerlitz,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
gongyangming-hv44wF8Li93QT0dZR+AlfA,
xiaokun-hv44wF8Li93QT0dZR+AlfA,
tangchaofei-hv44wF8Li93QT0dZR+AlfA,
haifeng.wei-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
lisheng011-hv44wF8Li93QT0dZR+AlfA,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA,
linuxarm-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <CAG53R5UTc8xF4TdRJm3ASv6PQ-JxhW7vDgXpFtYqX2tz_58UeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 2016/3/15 2:20, Parav Pandit wrote:
>>>
>>> Since SRQ is not supported in this driver version, can you keep
>>> remaining code base also to not bother about SRQ specifically
>>> poll_cq_one, modify_qp, destroy_qp etc?
>>> SRQ support can come as complete additional patch along with cmd_mask,
>>> callbacks and rest of the code.
>>>
>>> .
>> Sorry, I see your review in time.
>> Sure, SRQ is not supported in current roce driver. I have verified the function
>> for RDMA. It is not influence. For your question, we need to analyse it scientific.
>> after that, i will reply your doubt, is that ok?
>
> Yes. No problem.
>
> .
>
Hi, Parav Pandit
I have analyse and discuss with your reviewing. I considered that the srq is only the
condition branch in verbs and without independent function, so reserved it.I have delete the relative
function with srq independently.
if delete the branch operation with srq, it feel be inconvenient to understand
thanks
Lijun Ou
--
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 2/2 net-next v3.16]r8169: Place rtl_netdev_opts after alls functions is ready
From: Corcodel Marian @ 2016-03-19 13:10 UTC (permalink / raw)
To: netdev; +Cc: Francois Romieu, Corcodel Marian
In-Reply-To: <1458393027-1927-1-git-send-email-asd@marian1000.go.ro>
On multi cpu is posible do not keep in track alls tasks and
rtl_netdev_opts is placed after alls functions is fixed on structure
(rtl8169_private) and after MAC ADDRESS is added on structure.
Signed-off-by: Corcodel Marian <asd@marian1000.go.ro>
---
drivers/net/ethernet/realtek/r8169.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 2594bbb..c798349 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -7008,7 +7008,6 @@ rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
}
SET_NETDEV_DEV(dev, &pdev->dev);
- dev->netdev_ops = &rtl_netdev_ops;
tp = netdev_priv(dev);
tp->dev = dev;
tp->pci_dev = pdev;
@@ -7152,6 +7151,7 @@ rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
for (i = 0; i < ETH_ALEN; i++)
dev->dev_addr[i] = RTL_R8(MAC0 + i);
+ dev->netdev_ops = &rtl_netdev_ops;
dev->ethtool_ops = &rtl8169_ethtool_ops;
dev->watchdog_timeo = RTL8169_TX_TIMEOUT;
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2 net-next v3.16]r8169: Disable latency timer on pci express
From: Corcodel Marian @ 2016-03-19 13:10 UTC (permalink / raw)
To: netdev; +Cc: Francois Romieu, Corcodel Marian
On pci express interface not support latency timer.
Signed-off-by: Corcodel Marian <asd@marian1000.go.ro>
---
drivers/net/ethernet/realtek/r8169.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 61623e9..2594bbb 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3757,8 +3757,8 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
dprintk("Set MAC Reg C+CR Offset 0x82h = 0x01h\n");
RTL_W8(0x82, 0x01);
}
-
- pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40);
+ if (!tp->pci_dev->pcie_cap)
+ pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40);
if (tp->mac_version <= RTL_GIGA_MAC_VER_06)
pci_write_config_byte(tp->pci_dev, PCI_CACHE_LINE_SIZE, 0x08);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 3/4] infiniband: hns: add Hisilicon RoCE support(driver code)
From: Parav Pandit @ 2016-03-19 14:24 UTC (permalink / raw)
To: oulijun
Cc: Wei Hu(Xavier), Doug Ledford, Hefty, Sean, Hal Rosenstock,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
jiri-VPRAkNaXOzVWk0Htik3J/w, Or Gerlitz,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
gongyangming-hv44wF8Li93QT0dZR+AlfA,
xiaokun-hv44wF8Li93QT0dZR+AlfA,
tangchaofei-hv44wF8Li93QT0dZR+AlfA,
haifeng.wei-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
lisheng011-hv44wF8Li93QT0dZR+AlfA,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA,
linuxarm-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <56ED37C0.6090907-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
On Sat, Mar 19, 2016 at 4:58 PM, oulijun <oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
> On 2016/3/15 2:20, Parav Pandit wrote:
>>>>
>>>> Since SRQ is not supported in this driver version, can you keep
>>>> remaining code base also to not bother about SRQ specifically
>>>> poll_cq_one, modify_qp, destroy_qp etc?
>>>> SRQ support can come as complete additional patch along with cmd_mask,
>>>> callbacks and rest of the code.
>>>>
>>>> .
>>> Sorry, I see your review in time.
>>> Sure, SRQ is not supported in current roce driver. I have verified the function
>>> for RDMA. It is not influence. For your question, we need to analyse it scientific.
>>> after that, i will reply your doubt, is that ok?
>>
>> Yes. No problem.
>>
>> .
>>
> Hi, Parav Pandit
> I have analyse and discuss with your reviewing. I considered that the srq is only the
> condition branch in verbs and without independent function, so reserved it.I have delete the relative
> function with srq independently.
> if delete the branch operation with srq, it feel be inconvenient to understand
>
o.k. If I understand correctly, new patch will be without srq functionality.
If thats the case, that makes review and maintainability easier.
Thanks.
Parav
--
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 net-next v31.16]r8169: Consolided dev->features bedore adding netdev ethtool operations
From: Corcodel Marian @ 2016-03-19 15:16 UTC (permalink / raw)
To: netdev; +Cc: Francois Romieu, Corcodel Marian
Consolide dev->features before adding netdev, ethtool operations
on driver-private
Signed-off-by: Corcodel Marian <asd@marian1000.go.ro>
---
drivers/net/ethernet/realtek/r8169.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index c798349..a57b650 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3757,6 +3757,7 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
dprintk("Set MAC Reg C+CR Offset 0x82h = 0x01h\n");
RTL_W8(0x82, 0x01);
}
+
if (!tp->pci_dev->pcie_cap)
pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40);
@@ -7151,17 +7152,18 @@ rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
for (i = 0; i < ETH_ALEN; i++)
dev->dev_addr[i] = RTL_R8(MAC0 + i);
+ /* don't enable SG, IP_CSUM and TSO by default - it might not work
+ * properly for all devices */
+ dev->features |= NETIF_F_RXCSUM |
+ NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX;
+
+
dev->netdev_ops = &rtl_netdev_ops;
dev->ethtool_ops = &rtl8169_ethtool_ops;
dev->watchdog_timeo = RTL8169_TX_TIMEOUT;
netif_napi_add(dev, &tp->napi, rtl8169_poll, R8169_NAPI_WEIGHT);
- /* don't enable SG, IP_CSUM and TSO by default - it might not work
- * properly for all devices */
- dev->features |= NETIF_F_RXCSUM |
- NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX;
-
dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO |
NETIF_F_RXCSUM | NETIF_F_HW_VLAN_CTAG_TX |
NETIF_F_HW_VLAN_CTAG_RX;
--
2.1.4
^ permalink raw reply related
* [PATCH v2] sctp: align MTU to a word
From: Marcelo Ricardo Leitner @ 2016-03-19 15:17 UTC (permalink / raw)
To: netdev; +Cc: Eric Dumazet, Neil Horman, Vlad Yasevich, linux-sctp
SCTP is a protocol that is aligned to a word (4 bytes). Thus using bare
MTU can sometimes return values that are not aligned, like for loopback,
which is 65536 but ipv4_mtu() limits that to 65535. This mis-alignment
will cause the last non-aligned bytes to never be used and can cause
issues with congestion control.
So it's better to just consider a lower MTU and keep congestion control
calcs saner as they are based on PMTU.
Same applies to icmp frag needed messages, which is also fixed by this
patch.
One other effect of this is the inability to send MTU-sized packet
without queueing or fragmentation and without hitting Nagle. As the
check performed at sctp_packet_can_append_data():
if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead)
/* Enough data queued to fill a packet */
return SCTP_XMIT_OK;
with the above example of MTU, if there are no other messages queued,
one cannot send a packet that just fits one packet (65532 bytes) and
without causing DATA chunk fragmentation or a delay.
v2:
- Added WORD_TRUNC macro
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
---
include/net/sctp/sctp.h | 8 +++++---
net/sctp/associola.c | 3 ++-
net/sctp/input.c | 3 ++-
net/sctp/transport.c | 4 ++--
4 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 835aa2ed987092634a4242314e9eabb51d1e4e35..ad2136caa7d65fdc0f51e4c7ad3a526c2f39660d 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -82,6 +82,11 @@
#define SCTP_PROTOSW_FLAG INET_PROTOSW_PERMANENT
#endif
+/* Round an int up to the next multiple of 4. */
+#define WORD_ROUND(s) (((s)+3)&~3)
+/* Truncate to the previous multiple of 4. */
+#define WORD_TRUNC(s) ((s)&~3)
+
/*
* Function declarations.
*/
@@ -475,9 +480,6 @@ for (pos = chunk->subh.fwdtsn_hdr->skip;\
(void *)pos <= (void *)chunk->subh.fwdtsn_hdr->skip + end - sizeof(struct sctp_fwdtsn_skip);\
pos++)
-/* Round an int up to the next multiple of 4. */
-#define WORD_ROUND(s) (((s)+3)&~3)
-
/* External references. */
extern struct proto sctp_prot;
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index a19b3e60770382507050a56a172ffc5adb2f497a..e1849f3714adc47c22b92d8aaeba40b0287d2ba7 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -1406,7 +1406,8 @@ void sctp_assoc_sync_pmtu(struct sock *sk, struct sctp_association *asoc)
list_for_each_entry(t, &asoc->peer.transport_addr_list,
transports) {
if (t->pmtu_pending && t->dst) {
- sctp_transport_update_pmtu(sk, t, dst_mtu(t->dst));
+ sctp_transport_update_pmtu(sk, t,
+ WORD_TRUNC(dst_mtu(t->dst)));
t->pmtu_pending = 0;
}
if (!pmtu || (t->pathmtu < pmtu))
diff --git a/net/sctp/input.c b/net/sctp/input.c
index db76f1ab4ac2cb16b4568f0d9fbe4e3b90deaa1c..00b8445364e3d5045f0ff71d9e836c18e7c6a401 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -606,7 +606,8 @@ void sctp_v4_err(struct sk_buff *skb, __u32 info)
/* PMTU discovery (RFC1191) */
if (ICMP_FRAG_NEEDED == code) {
- sctp_icmp_frag_needed(sk, asoc, transport, info);
+ sctp_icmp_frag_needed(sk, asoc, transport,
+ WORD_TRUNC(info));
goto out_unlock;
} else {
if (ICMP_PROT_UNREACH == code) {
diff --git a/net/sctp/transport.c b/net/sctp/transport.c
index d517153891a6efca6242ce1a4b3d86afb9026542..9b6b48c7524e4b441a151b80f0babec81f539d49 100644
--- a/net/sctp/transport.c
+++ b/net/sctp/transport.c
@@ -226,7 +226,7 @@ void sctp_transport_pmtu(struct sctp_transport *transport, struct sock *sk)
}
if (transport->dst) {
- transport->pathmtu = dst_mtu(transport->dst);
+ transport->pathmtu = WORD_TRUNC(dst_mtu(transport->dst));
} else
transport->pathmtu = SCTP_DEFAULT_MAXSEGMENT;
}
@@ -280,7 +280,7 @@ void sctp_transport_route(struct sctp_transport *transport,
return;
}
if (transport->dst) {
- transport->pathmtu = dst_mtu(transport->dst);
+ transport->pathmtu = WORD_TRUNC(dst_mtu(transport->dst));
/* Initialize sk->sk_rcv_saddr, if the transport is the
* association's active path for getsockname().
--
2.5.0
^ permalink raw reply related
* [PATCH v2] sctp: keep fragmentation point aligned to word size
From: Marcelo Ricardo Leitner @ 2016-03-19 15:17 UTC (permalink / raw)
To: netdev; +Cc: Eric Dumazet, Neil Horman, Vlad Yasevich, linux-sctp
If the user supply a different fragmentation point or if there is a
network header that cause it to not be aligned, force it to be aligned.
Fragmentation point at a value that is not aligned is not optimal. It
causes extra padding to be used and has just no pros.
v2:
- Make use of the new WORD_TRUNC macro
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
---
include/net/sctp/sctp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index ad2136caa7d65fdc0f51e4c7ad3a526c2f39660d..65521cfdcadeee35d61f280165a387cc2164ab6d 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -431,7 +431,7 @@ static inline int sctp_frag_point(const struct sctp_association *asoc, int pmtu)
if (asoc->user_frag)
frag = min_t(int, frag, asoc->user_frag);
- frag = min_t(int, frag, SCTP_MAX_CHUNK_LEN);
+ frag = WORD_TRUNC(min_t(int, frag, SCTP_MAX_CHUNK_LEN));
return frag;
}
--
2.5.0
^ permalink raw reply related
* Guten Tag.
From: Anthony Victor @ 2016-03-19 14:32 UTC (permalink / raw)
To: Recipients
Sehr geehrte Damen und Herren,
ich bin Anthony Victor, ich habe ein gutes Geschaft Angebot fur Sie. Es gibt keine Risiko
und das ist ganz einfach. Antworten Sie bitte fur mehr info und Verfahren.
Beste Gru?e,
Sgt Anthony Victor
anthonyvictor2000@outlook.com
^ permalink raw reply
* Re: [RFC net-next 0/2] Create ancient subdirectories for old hardware
From: Joe Perches @ 2016-03-19 15:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20160318.231626.670272515350508280.davem@davemloft.net>
On Fri, 2016-03-18 at 23:16 -0400, David Miller wrote:
> From: Joe Perches <joe@perches.com> Date: Fri, 18 Mar 2016 19:28:02 -0700
> > On Fri, 2016-03-18 at 22:11 -0400, David Miller wrote:
> >> From: Joe Perches <joe@perches.com> Date: Fri, 18 Mar 2016 17:33:29 -0700
> >> > Maybe something like this:
> >> > Old, rare, and unsupported hardware should be exposed as ancient.
> >> >
> >> > The drivers for these ancient hardwares are generally untested with
> >> > current kernels.
> >>
> >> Moving drivers has a long term maintainence cost.
> >>
> >> If they've moved into drivers/net proper, we have to maintain
> >> them there forever.
> >
> > I don't doubt that.
Actually I rather do kind of doubt that.
Look for instance at what's proposed now for drivers/isdn
which realistically, could have been in drivers/net.
Also, various bits of hardware support have already been
dropped from drivers/net. The 3c503, ni52 and others
come to mind. Token Ring support too.
Today, I expect there aren't many Packet Engines devices,
either hamachi or yellowfin, still being used, especially
with kernel versions > 4.
> > All files are still in drivers/net, just possibly in
> > separate subdirectories for easier visibility to
> > determine if changes like what were proposed for cxgb
> > should actually be done or not.
>
> You don't understand my concern, backporting patches to -stable
> releases is more painful if you move the driver anywhere other
> than where it has been for years.
>
> I'm not entertaining this idea, sorry Joe.
I do understand your concern. Backporting patches to obsolete
hardware shouldn't much be necessary as obsolete hardware,
as you wrote yourself, simply doens't get much testing.
Archaic stuff should eventually get sifted out altogether.
Marking drivers as archaic at least allows people that use
use the older devices to object and maybe actually step up
to maintain them too.
^ permalink raw reply
* [PATCH net v2 0/3] Tunneling fixes
From: Jesse Gross @ 2016-03-19 16:31 UTC (permalink / raw)
To: David Miller; +Cc: netdev
This series fixes a problem that was reported where encapsulated packets
do not have their encapsulation offload markers stripped off when being
decapsulated. This causes a significant performance drop if the packets
are later retransmitted.
Fixing this revealed two other bugs which are also addressed as prerequisites:
* GRO can aggregate packets for multiple layers of encapsulation which the
stack cannot properly handle.
* IPIP packets which are combined by GRO are not marked properly with their
GSO type.
Note that this is based off the net-next tree as the current target for
bug fixes.
v2: No code changes, just additional information in commit messages and
a new cover letter.
Jesse Gross (3):
ipip: Properly mark ipip GRO packets as encapsulated.
tunnels: Don't apply GRO to multiple layers of encapsulation.
tunnels: Remove encapsulation offloads on decap.
include/linux/netdevice.h | 4 ++--
include/net/ip_tunnels.h | 16 ++++++++++++++++
net/core/dev.c | 2 +-
net/ipv4/af_inet.c | 24 ++++++++++++++++++++++--
net/ipv4/fou.c | 13 +++++++++++--
net/ipv4/gre_offload.c | 5 +++++
net/ipv4/ip_tunnel_core.c | 3 ++-
net/ipv4/udp_offload.c | 6 +++---
net/ipv6/ip6_offload.c | 15 ++++++++++++++-
net/ipv6/sit.c | 6 ++++--
10 files changed, 80 insertions(+), 14 deletions(-)
--
2.5.0
^ permalink raw reply
* [PATCH net v2 1/3] ipip: Properly mark ipip GRO packets as encapsulated.
From: Jesse Gross @ 2016-03-19 16:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Patrick Boutilier, Eric Dumazet
In-Reply-To: <1458405122-12565-1-git-send-email-jesse@kernel.org>
ipip encapsulated packets can be merged together by GRO but the result
does not have the proper GSO type set or even marked as being
encapsulated at all. Later retransmission of these packets will likely
fail if the device does not support ipip offloads. This is similar to
the issue resolved in IPv6 sit in feec0cb3
("ipv6: gro: support sit protocol").
Reported-by: Patrick Boutilier <boutilpj@ednet.ns.ca>
Fixes: 9667e9bb ("ipip: Add gro callbacks to ipip offload")
Tested-by: Patrick Boutilier <boutilpj@ednet.ns.ca>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jesse Gross <jesse@kernel.org>
---
v2: No change.
---
net/ipv4/af_inet.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 0cc923f..9659233 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1448,6 +1448,13 @@ out_unlock:
return err;
}
+static int ipip_gro_complete(struct sk_buff *skb, int nhoff)
+{
+ skb->encapsulation = 1;
+ skb_shinfo(skb)->gso_type |= SKB_GSO_IPIP;
+ return inet_gro_complete(skb, nhoff);
+}
+
int inet_ctl_sock_create(struct sock **sk, unsigned short family,
unsigned short type, unsigned char protocol,
struct net *net)
@@ -1676,7 +1683,7 @@ static const struct net_offload ipip_offload = {
.callbacks = {
.gso_segment = inet_gso_segment,
.gro_receive = inet_gro_receive,
- .gro_complete = inet_gro_complete,
+ .gro_complete = ipip_gro_complete,
},
};
--
2.5.0
^ permalink raw reply related
* [PATCH net v2 2/3] tunnels: Don't apply GRO to multiple layers of encapsulation.
From: Jesse Gross @ 2016-03-19 16:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1458405122-12565-1-git-send-email-jesse@kernel.org>
When drivers express support for TSO of encapsulated packets, they
only mean that they can do it for one layer of encapsulation.
Supporting additional levels would mean updating, at a minimum,
more IP length fields and they are unaware of this.
No encapsulation device expresses support for handling offloaded
encapsulated packets, so we won't generate these types of frames
in the transmit path. However, GRO doesn't have a check for
multiple levels of encapsulation and will attempt to build them.
UDP tunnel GRO actually does prevent this situation but it only
handles multiple UDP tunnels stacked on top of each other. This
generalizes that solution to prevent any kind of tunnel stacking
that would cause problems.
Fixes: bf5a755f ("net-gre-gro: Add GRE support to the GRO stack")
Signed-off-by: Jesse Gross <jesse@kernel.org>
---
v2: No change.
---
include/linux/netdevice.h | 4 ++--
net/core/dev.c | 2 +-
net/ipv4/af_inet.c | 15 ++++++++++++++-
net/ipv4/gre_offload.c | 5 +++++
net/ipv4/udp_offload.c | 6 +++---
net/ipv6/ip6_offload.c | 15 ++++++++++++++-
6 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index be693b3..f9eebd5 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2096,8 +2096,8 @@ struct napi_gro_cb {
/* This is non-zero if the packet may be of the same flow. */
u8 same_flow:1;
- /* Used in udp_gro_receive */
- u8 udp_mark:1;
+ /* Used in tunnel GRO receive */
+ u8 encap_mark:1;
/* GRO checksum is valid */
u8 csum_valid:1;
diff --git a/net/core/dev.c b/net/core/dev.c
index edb7179..43c74ca 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4438,7 +4438,7 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
NAPI_GRO_CB(skb)->same_flow = 0;
NAPI_GRO_CB(skb)->flush = 0;
NAPI_GRO_CB(skb)->free = 0;
- NAPI_GRO_CB(skb)->udp_mark = 0;
+ NAPI_GRO_CB(skb)->encap_mark = 0;
NAPI_GRO_CB(skb)->gro_remcsum_start = 0;
/* Setup for GRO checksum validation */
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 9659233..0fefba6 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1380,6 +1380,19 @@ out:
return pp;
}
+static struct sk_buff **ipip_gro_receive(struct sk_buff **head,
+ struct sk_buff *skb)
+{
+ if (NAPI_GRO_CB(skb)->encap_mark) {
+ NAPI_GRO_CB(skb)->flush = 1;
+ return NULL;
+ }
+
+ NAPI_GRO_CB(skb)->encap_mark = 1;
+
+ return inet_gro_receive(head, skb);
+}
+
#define SECONDS_PER_DAY 86400
/* inet_current_timestamp - Return IP network timestamp
@@ -1682,7 +1695,7 @@ static struct packet_offload ip_packet_offload __read_mostly = {
static const struct net_offload ipip_offload = {
.callbacks = {
.gso_segment = inet_gso_segment,
- .gro_receive = inet_gro_receive,
+ .gro_receive = ipip_gro_receive,
.gro_complete = ipip_gro_complete,
},
};
diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
index 540866d..dd03161 100644
--- a/net/ipv4/gre_offload.c
+++ b/net/ipv4/gre_offload.c
@@ -126,6 +126,11 @@ static struct sk_buff **gre_gro_receive(struct sk_buff **head,
struct packet_offload *ptype;
__be16 type;
+ if (NAPI_GRO_CB(skb)->encap_mark)
+ goto out;
+
+ NAPI_GRO_CB(skb)->encap_mark = 1;
+
off = skb_gro_offset(skb);
hlen = off + sizeof(*greh);
greh = skb_gro_header_fast(skb, off);
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 8a3405a..8007f73 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -311,14 +311,14 @@ struct sk_buff **udp_gro_receive(struct sk_buff **head, struct sk_buff *skb,
unsigned int off = skb_gro_offset(skb);
int flush = 1;
- if (NAPI_GRO_CB(skb)->udp_mark ||
+ if (NAPI_GRO_CB(skb)->encap_mark ||
(skb->ip_summed != CHECKSUM_PARTIAL &&
NAPI_GRO_CB(skb)->csum_cnt == 0 &&
!NAPI_GRO_CB(skb)->csum_valid))
goto out;
- /* mark that this skb passed once through the udp gro layer */
- NAPI_GRO_CB(skb)->udp_mark = 1;
+ /* mark that this skb passed once through the tunnel gro layer */
+ NAPI_GRO_CB(skb)->encap_mark = 1;
rcu_read_lock();
uo_priv = rcu_dereference(udp_offload_base);
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index eeca943..82e9f30 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -258,6 +258,19 @@ out:
return pp;
}
+static struct sk_buff **sit_gro_receive(struct sk_buff **head,
+ struct sk_buff *skb)
+{
+ if (NAPI_GRO_CB(skb)->encap_mark) {
+ NAPI_GRO_CB(skb)->flush = 1;
+ return NULL;
+ }
+
+ NAPI_GRO_CB(skb)->encap_mark = 1;
+
+ return ipv6_gro_receive(head, skb);
+}
+
static int ipv6_gro_complete(struct sk_buff *skb, int nhoff)
{
const struct net_offload *ops;
@@ -302,7 +315,7 @@ static struct packet_offload ipv6_packet_offload __read_mostly = {
static const struct net_offload sit_offload = {
.callbacks = {
.gso_segment = ipv6_gso_segment,
- .gro_receive = ipv6_gro_receive,
+ .gro_receive = sit_gro_receive,
.gro_complete = sit_gro_complete,
},
};
--
2.5.0
^ permalink raw reply related
* [PATCH net v2 3/3] tunnels: Remove encapsulation offloads on decap.
From: Jesse Gross @ 2016-03-19 16:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Ramu Ramamurthy
In-Reply-To: <1458405122-12565-1-git-send-email-jesse@kernel.org>
If a packet is either locally encapsulated or processed through GRO
it is marked with the offloads that it requires. However, when it is
decapsulated these tunnel offload indications are not removed. This
means that if we receive an encapsulated TCP packet, aggregate it with
GRO, decapsulate, and retransmit the resulting frame on a NIC that does
not support encapsulation, we won't be able to take advantage of hardware
offloads even though it is just a simple TCP packet at this point.
This fixes the problem by stripping off encapsulation offload indications
when packets are decapsulated.
The performance impacts of this bug are significant. In a test where a
Geneve encapsulated TCP stream is sent to a hypervisor, GRO'ed, decapsulated,
and bridged to a VM performance is improved by 60% (5Gbps->8Gbps) as a
result of avoiding unnecessary segmentation at the VM tap interface.
Reported-by: Ramu Ramamurthy <sramamur@linux.vnet.ibm.com>
Fixes: 68c33163 ("v4 GRE: Add TCP segmentation offload for GRE")
Signed-off-by: Jesse Gross <jesse@kernel.org>
---
v2: Additional performance numbers in the commit message.
---
include/net/ip_tunnels.h | 16 ++++++++++++++++
net/ipv4/fou.c | 13 +++++++++++--
net/ipv4/ip_tunnel_core.c | 3 ++-
net/ipv6/sit.c | 6 ++++--
4 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
index c35dda9..56050f9 100644
--- a/include/net/ip_tunnels.h
+++ b/include/net/ip_tunnels.h
@@ -305,6 +305,22 @@ struct metadata_dst *iptunnel_metadata_reply(struct metadata_dst *md,
struct sk_buff *iptunnel_handle_offloads(struct sk_buff *skb, int gso_type_mask);
+static inline int iptunnel_pull_offloads(struct sk_buff *skb)
+{
+ if (skb_is_gso(skb)) {
+ int err;
+
+ err = skb_unclone(skb, GFP_ATOMIC);
+ if (unlikely(err))
+ return err;
+ skb_shinfo(skb)->gso_type &= ~(NETIF_F_GSO_ENCAP_ALL >>
+ NETIF_F_GSO_SHIFT);
+ }
+
+ skb->encapsulation = 0;
+ return 0;
+}
+
static inline void iptunnel_xmit_stats(struct net_device *dev, int pkt_len)
{
if (pkt_len > 0) {
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index 7804842..a0586b4 100644
--- a/net/ipv4/fou.c
+++ b/net/ipv4/fou.c
@@ -48,7 +48,7 @@ static inline struct fou *fou_from_sock(struct sock *sk)
return sk->sk_user_data;
}
-static void fou_recv_pull(struct sk_buff *skb, size_t len)
+static int fou_recv_pull(struct sk_buff *skb, size_t len)
{
struct iphdr *iph = ip_hdr(skb);
@@ -59,6 +59,7 @@ static void fou_recv_pull(struct sk_buff *skb, size_t len)
__skb_pull(skb, len);
skb_postpull_rcsum(skb, udp_hdr(skb), len);
skb_reset_transport_header(skb);
+ return iptunnel_pull_offloads(skb);
}
static int fou_udp_recv(struct sock *sk, struct sk_buff *skb)
@@ -68,9 +69,14 @@ static int fou_udp_recv(struct sock *sk, struct sk_buff *skb)
if (!fou)
return 1;
- fou_recv_pull(skb, sizeof(struct udphdr));
+ if (fou_recv_pull(skb, sizeof(struct udphdr)))
+ goto drop;
return -fou->protocol;
+
+drop:
+ kfree_skb(skb);
+ return 0;
}
static struct guehdr *gue_remcsum(struct sk_buff *skb, struct guehdr *guehdr,
@@ -170,6 +176,9 @@ static int gue_udp_recv(struct sock *sk, struct sk_buff *skb)
__skb_pull(skb, sizeof(struct udphdr) + hdrlen);
skb_reset_transport_header(skb);
+ if (iptunnel_pull_offloads(skb))
+ goto drop;
+
return -guehdr->proto_ctype;
drop:
diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
index d27276f..02dd990 100644
--- a/net/ipv4/ip_tunnel_core.c
+++ b/net/ipv4/ip_tunnel_core.c
@@ -114,7 +114,8 @@ int iptunnel_pull_header(struct sk_buff *skb, int hdr_len, __be16 inner_proto,
skb->vlan_tci = 0;
skb_set_queue_mapping(skb, 0);
skb_scrub_packet(skb, xnet);
- return 0;
+
+ return iptunnel_pull_offloads(skb);
}
EXPORT_SYMBOL_GPL(iptunnel_pull_header);
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index f45b8ff..8338430 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -681,14 +681,16 @@ static int ipip6_rcv(struct sk_buff *skb)
skb->mac_header = skb->network_header;
skb_reset_network_header(skb);
IPCB(skb)->flags = 0;
- skb->protocol = htons(ETH_P_IPV6);
+ skb->dev = tunnel->dev;
if (packet_is_spoofed(skb, iph, tunnel)) {
tunnel->dev->stats.rx_errors++;
goto out;
}
- __skb_tunnel_rx(skb, tunnel->dev, tunnel->net);
+ if (iptunnel_pull_header(skb, 0, htons(ETH_P_IPV6),
+ !net_eq(tunnel->net, dev_net(tunnel->dev))))
+ goto out;
err = IP_ECN_decapsulate(iph, skb);
if (unlikely(err)) {
--
2.5.0
^ permalink raw reply related
* Re: [PATCH net 1/3] ipip: Properly mark ipip GRO packets as encapsulated.
From: Jesse Gross @ 2016-03-19 16:33 UTC (permalink / raw)
To: David Miller; +Cc: Linux Kernel Network Developers, Patrick Boutilier
In-Reply-To: <20160318.231207.637794925156978876.davem@davemloft.net>
On Fri, Mar 18, 2016 at 8:12 PM, David Miller <davem@davemloft.net> wrote:
>
> Jesse, can you repost this series with a patch introductory "PATCH
> 0/3" email explaining things at a high level about what this series is
> doing?
>
> Thanks.
Sure, I just sent a v2 with a cover letter.
^ permalink raw reply
* [PATCH v7] isdn: Use ktime_t instead of 'struct timeval'
From: Tina Ruchandani @ 2016-03-19 18:21 UTC (permalink / raw)
To: netdev; +Cc: y2038, Karsten Keil, David Miller, Arnd Bergmnann, Kernel
'struct timeval' uses 32-bit representation for seconds which will
overflow in year 2038 and beyond. mISDN/clock.c needs to compute and
store elapsed time in intervals of 125 microseconds. This patch replaces
the usage of 'struct timeval' with 64-bit ktime_t which is y2038 safe.
The patch also replaces do_gettimeofday() (wall-clock time) with
ktime_get() (monotonic time) since we only care about elapsed time here.
Signed-off-by: Tina Ruchandani <ruchandani.tina@gmail.com>
Suggested-by: Arnd Bergmnann <arnd@arndb.de>
Suggested-by: David Miller <davem@davemloft.net>
---
Changes in v7:
- Upodate variable names to remove mentions of 'tv' for timeval
Changes in v6:
- Fix compilation errors caused by bad code editing
Changes in v5:
- Apply cleanly to net-next
Changes in v4:
- Fix compile error (NS_PER_SEC -> NSEC_PER_SEC)
Changes in v3:
- Use division scheme suggested by Arnd Bergmann to avoid
a (64-bit variable) / (32-bit variable) expression.
Changes in v2:
- Avoid possible truncation bug caused by assigning ktime_us_delta
output to a 16-bit number.
- Use ktime_us_delta, more concise than a combination of ktime_sub
and ktime_to_us.
---
drivers/isdn/mISDN/clock.c | 69 +++++++++++++++++++---------------------------
include/linux/mISDNif.h | 2 +-
2 files changed, 30 insertions(+), 41 deletions(-)
diff --git a/drivers/isdn/mISDN/clock.c b/drivers/isdn/mISDN/clock.c
index 693fb7c..f8f659f 100644
--- a/drivers/isdn/mISDN/clock.c
+++ b/drivers/isdn/mISDN/clock.c
@@ -37,6 +37,7 @@
#include <linux/types.h>
#include <linux/stddef.h>
#include <linux/spinlock.h>
+#include <linux/ktime.h>
#include <linux/mISDNif.h>
#include <linux/export.h>
#include "core.h"
@@ -45,15 +46,15 @@ static u_int *debug;
static LIST_HEAD(iclock_list);
static DEFINE_RWLOCK(iclock_lock);
static u16 iclock_count; /* counter of last clock */
-static struct timeval iclock_tv; /* time stamp of last clock */
-static int iclock_tv_valid; /* already received one timestamp */
+static ktime_t iclock_timestamp; /* time stamp of last clock */
+static int iclock_timestamp_valid; /* already received one timestamp */
static struct mISDNclock *iclock_current;
void
mISDN_init_clock(u_int *dp)
{
debug = dp;
- do_gettimeofday(&iclock_tv);
+ iclock_timestamp = ktime_get();
}
static void
@@ -86,7 +87,7 @@ select_iclock(void)
}
if (bestclock != iclock_current) {
/* no clock received yet */
- iclock_tv_valid = 0;
+ iclock_timestamp_valid = 0;
}
iclock_current = bestclock;
}
@@ -139,12 +140,11 @@ mISDN_unregister_clock(struct mISDNclock *iclock)
EXPORT_SYMBOL(mISDN_unregister_clock);
void
-mISDN_clock_update(struct mISDNclock *iclock, int samples, struct timeval *tv)
+mISDN_clock_update(struct mISDNclock *iclock, int samples, ktime_t *timestamp)
{
u_long flags;
- struct timeval tv_now;
- time_t elapsed_sec;
- int elapsed_8000th;
+ ktime_t timestamp_now;
+ u16 delta;
write_lock_irqsave(&iclock_lock, flags);
if (iclock_current != iclock) {
@@ -156,33 +156,27 @@ mISDN_clock_update(struct mISDNclock *iclock, int samples, struct timeval *tv)
write_unlock_irqrestore(&iclock_lock, flags);
return;
}
- if (iclock_tv_valid) {
+ if (iclock_timestamp_valid) {
/* increment sample counter by given samples */
iclock_count += samples;
- if (tv) { /* tv must be set, if function call is delayed */
- iclock_tv.tv_sec = tv->tv_sec;
- iclock_tv.tv_usec = tv->tv_usec;
- } else
- do_gettimeofday(&iclock_tv);
+ if (timestamp) { /* timestamp must be set, if function call is delayed */
+ iclock_timestamp = *timestamp;
+ } else {
+ iclock_timestamp = ktime_get();
+ }
} else {
/* calc elapsed time by system clock */
- if (tv) { /* tv must be set, if function call is delayed */
- tv_now.tv_sec = tv->tv_sec;
- tv_now.tv_usec = tv->tv_usec;
- } else
- do_gettimeofday(&tv_now);
- elapsed_sec = tv_now.tv_sec - iclock_tv.tv_sec;
- elapsed_8000th = (tv_now.tv_usec / 125)
- - (iclock_tv.tv_usec / 125);
- if (elapsed_8000th < 0) {
- elapsed_sec -= 1;
- elapsed_8000th += 8000;
+ if (timestamp) { /* timestamp must be set, if function call is delayed */
+ timestamp_now = *timestamp;
+ } else {
+ timestamp_now = ktime_get();
}
+ delta = ktime_divns(ktime_sub(timestamp_now, iclock_timestamp),
+ (NSEC_PER_SEC / 8000));
/* add elapsed time to counter and set new timestamp */
- iclock_count += elapsed_sec * 8000 + elapsed_8000th;
- iclock_tv.tv_sec = tv_now.tv_sec;
- iclock_tv.tv_usec = tv_now.tv_usec;
- iclock_tv_valid = 1;
+ iclock_count += delta;
+ iclock_timestamp = timestamp_now;
+ iclock_timestamp_valid = 1;
if (*debug & DEBUG_CLOCK)
printk("Received first clock from source '%s'.\n",
iclock_current ? iclock_current->name : "nothing");
@@ -195,22 +189,17 @@ unsigned short
mISDN_clock_get(void)
{
u_long flags;
- struct timeval tv_now;
- time_t elapsed_sec;
- int elapsed_8000th;
+ ktime_t timestamp_now;
+ u16 delta;
u16 count;
read_lock_irqsave(&iclock_lock, flags);
/* calc elapsed time by system clock */
- do_gettimeofday(&tv_now);
- elapsed_sec = tv_now.tv_sec - iclock_tv.tv_sec;
- elapsed_8000th = (tv_now.tv_usec / 125) - (iclock_tv.tv_usec / 125);
- if (elapsed_8000th < 0) {
- elapsed_sec -= 1;
- elapsed_8000th += 8000;
- }
+ timestamp_now = ktime_get();
+ delta = ktime_divns(ktime_sub(timestamp_now, iclock_timestamp),
+ (NSEC_PER_SEC / 8000));
/* add elapsed time to counter */
- count = iclock_count + elapsed_sec * 8000 + elapsed_8000th;
+ count = iclock_count + delta;
read_unlock_irqrestore(&iclock_lock, flags);
return count;
}
diff --git a/include/linux/mISDNif.h b/include/linux/mISDNif.h
index 246a352..ac02c54 100644
--- a/include/linux/mISDNif.h
+++ b/include/linux/mISDNif.h
@@ -596,7 +596,7 @@ static inline struct mISDNdevice *dev_to_mISDN(struct device *dev)
}
extern void set_channel_address(struct mISDNchannel *, u_int, u_int);
-extern void mISDN_clock_update(struct mISDNclock *, int, struct timeval *);
+extern void mISDN_clock_update(struct mISDNclock *, int, ktime_t *);
extern unsigned short mISDN_clock_get(void);
extern const char *mISDNDevName4ch(struct mISDNchannel *);
--
1.9.1
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply related
* ip-token: unable to remove a token & multi-token handling & concurrent use w/ EUI64/privacy
From: Robin H. Johnson @ 2016-03-19 18:53 UTC (permalink / raw)
To: netdev, daniel
Hi,
Playing around with IPv6 tokens, I ran into a problem:
Once you have a token set on an interface, it's impossible to remove it!
# ip token set :: dev eth0
RTNETLINK answers: Invalid argument
This is a side-effect of rejecting ipv6_addr_any in inet6_set_iftoken.
While this gets fixed, I have two related feature requests for this:
- Please make it possible to configure multiple tokens on an interface:
Use case: Deploying local services on well-known addresses inside a
network without explicit prefix configuration.
- Adding a token causes other address generation methods to be disabled,
this is problematic if you wish to prefer privacy addresses for
outbound connections.
Design suggestion:
Convert from using a single token to using a list of tokens, with an
explicit default IPv6-any-addr (::) in the list, to represent that
other address generation should ALSO take place (EUI64/privacy).
Deletion of the any-addr from the list should disable EUI64/privacy
addresses.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
^ permalink raw reply
* [PATCH] gen_stats.c: Add description for cpu argument
From: Luis de Bethencourt @ 2016-03-19 21:19 UTC (permalink / raw)
To: linux-kernel; +Cc: davem, netdev, Luis de Bethencourt
Function gnet_stats_copy_basic is missing the description of the cpu
argument in the documentation. Adding it.
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
---
Hi,
Noticed this issue when running make htmldocs. I got the following warning:
.//net/core/gen_stats.c:155: warning: No description found for parameter 'cpu'
Thanks,
Luis
net/core/gen_stats.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/gen_stats.c b/net/core/gen_stats.c
index 1e2f46a..e640462 100644
--- a/net/core/gen_stats.c
+++ b/net/core/gen_stats.c
@@ -140,6 +140,7 @@ EXPORT_SYMBOL(__gnet_stats_copy_basic);
/**
* gnet_stats_copy_basic - copy basic statistics into statistic TLV
* @d: dumping handle
+ * @cpu: copy statistic per cpu
* @b: basic statistics
*
* Appends the basic statistics to the top level TLV created by
--
2.5.1
^ permalink raw reply related
* [PATCH] net: sched: Add description for cpu_bstats argument
From: Luis de Bethencourt @ 2016-03-19 21:31 UTC (permalink / raw)
To: linux-kernel; +Cc: davem, netdev, edumazet, ast, Luis de Bethencourt
Commit 22e0f8b9322c ("net: sched: make bstats per cpu and estimator RCU safe")
added the argument cpu_bstats to functions gen_new_estimator and
gen_replace_estimator and now the descriptions of these are missing for the
documentation. Adding them.
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
---
Hi,
Noticed these missing descriptions when running make htmldocs.
Got the following warnings:
.//net/core/gen_estimator.c:212: warning: No description found for parameter 'cpu_bstats'
.//net/core/gen_estimator.c:303: warning: No description found for parameter 'cpu_bstats'
Thanks :)
Luis
net/core/gen_estimator.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/gen_estimator.c b/net/core/gen_estimator.c
index 92d886f..4573d81 100644
--- a/net/core/gen_estimator.c
+++ b/net/core/gen_estimator.c
@@ -191,6 +191,7 @@ struct gen_estimator *gen_find_node(const struct gnet_stats_basic_packed *bstats
/**
* gen_new_estimator - create a new rate estimator
* @bstats: basic statistics
+ * @cpu_bstats: bstats per cpu
* @rate_est: rate estimator statistics
* @stats_lock: statistics lock
* @opt: rate estimator configuration TLV
@@ -287,6 +288,7 @@ EXPORT_SYMBOL(gen_kill_estimator);
/**
* gen_replace_estimator - replace rate estimator configuration
* @bstats: basic statistics
+ * @cpu_bstats: bstats per cpu
* @rate_est: rate estimator statistics
* @stats_lock: statistics lock
* @opt: rate estimator configuration TLV
--
2.5.1
^ permalink raw reply related
* AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)
From: Pali Rohár @ 2016-03-19 23:40 UTC (permalink / raw)
To: Luciano Coelho, Felipe Balbi, kev, Shahar Levi, Kalle Valo,
Andrew F. Davis, Guy Mishol, Yaniv Machani, Arik Nemtsov,
Gery Kahn, Felipe Balbi, Luciano Coelho
Cc: David Woodhouse, Pavel Machek, Aaro Koskinen, Ben Hutchings,
David Gnedt, Ivaylo Dimitrov, Sebastian Reichel, Tony Lindgren,
Nishanth Menon, linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: Text/Plain, Size: 846 bytes --]
Hi!
In linux-firmware repository [1] is missing AP firmware for TI wl1251
chip. There is only STA firmware wl1251-fw.bin which supports managed
and ad-hoc modes.
For other TI wilink chips there are <CHIP>-ap.bin firmware files
(wl1271-fw-ap.bin and wl128x-fw-ap.bin) which support AP mode. But for
wl1251 firmware file with guessed name "wl1251-fw-ap.bin" is missing.
Do you have any idea what happened with AP firmware for ti wilink4
wl1251 wifi chip? Or where can be found? Guys from TI, can you help?
I see that STA firmware was added into linux-firmware tree in year 2013
by this pull request [2].
[1] - https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/ti-connectivity
[2] - http://thread.gmane.org/gmane.linux.kernel/1566500/focus=1571382
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/3] IB/hns: Add HiSilicon RoCE driver support
From: Leon Romanovsky @ 2016-03-20 6:23 UTC (permalink / raw)
To: Lijun Ou
Cc: dledford, sean.hefty, hal.rosenstock, davem, jeffrey.t.kirsher,
jiri, ogerlitz, linux-rdma, linux-kernel, netdev, gongyangming,
xiaokun, tangchaofei, haifeng.wei, yisen.zhuang, yankejian,
lisheng011, charles.chenxin, linuxarm
In-Reply-To: <1458384658-16759-3-git-send-email-oulijun@huawei.com>
On Sat, Mar 19, 2016 at 06:50:57PM +0800, Lijun Ou wrote:
> The driver for HiSilicon RoCE is a platform driver.
> The driver will support multiple versions of hardware. Currently only "v1"
> for hip06 SoC is supported.
> The driver includes two parts: common driver and hardware-specific
> operations. hns_roce_v1_hw.c and hns_roce_v1_hw.h are files for
> hardware-specific operations only for v1 engine, and other files(.c and .h)
> for common algorithm and common hardware operations.
>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> Signed-off-by: Wei Hu(Xavier) <xavier.huwei@huawei.com>
> Signed-off-by: Znlong <zhaonenglong@huawei.com>
> ---
> MAINTAINERS | 8 +
> drivers/infiniband/Kconfig | 1 +
> drivers/infiniband/hw/Makefile | 1 +
> drivers/infiniband/hw/hisilicon/hns/Kconfig | 10 +
> drivers/infiniband/hw/hisilicon/hns/Makefile | 9 +
> drivers/infiniband/hw/hisilicon/hns/hns_roce_ah.c | 110 +
> .../infiniband/hw/hisilicon/hns/hns_roce_alloc.c | 239 ++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_cmd.c | 338 +++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_cmd.h | 80 +
> .../infiniband/hw/hisilicon/hns/hns_roce_common.h | 308 +++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_cq.c | 436 +++
> .../infiniband/hw/hisilicon/hns/hns_roce_device.h | 794 ++++++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_eq.c | 758 ++++++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_eq.h | 133 +
> drivers/infiniband/hw/hisilicon/hns/hns_roce_icm.c | 578 ++++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_icm.h | 112 +
> .../infiniband/hw/hisilicon/hns/hns_roce_main.c | 1097 ++++++++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_mr.c | 605 +++++
> drivers/infiniband/hw/hisilicon/hns/hns_roce_pd.c | 124 +
> drivers/infiniband/hw/hisilicon/hns/hns_roce_qp.c | 841 ++++++
> .../infiniband/hw/hisilicon/hns/hns_roce_user.h | 31 +
> .../infiniband/hw/hisilicon/hns/hns_roce_v1_hw.c | 2835 ++++++++++++++++++++
> .../infiniband/hw/hisilicon/hns/hns_roce_v1_hw.h | 986 +++++++
> 23 files changed, 10434 insertions(+)
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/Kconfig
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/Makefile
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_ah.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_alloc.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_cmd.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_cmd.h
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_common.h
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_cq.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_device.h
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_eq.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_eq.h
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_icm.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_icm.h
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_main.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_mr.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_pd.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_qp.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_user.h
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_v1_hw.c
> create mode 100644 drivers/infiniband/hw/hisilicon/hns/hns_roce_v1_hw.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2933d90..0c7fac5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9878,6 +9878,14 @@ W: http://www.emulex.com
> S: Supported
> F: drivers/infiniband/hw/ocrdma/
>
> +HISILICON ROCE DRIVER
> +M: Wei Hu(Xavier) <xavier.huwei@huawei.com>
> +M: Lijun Ou <oulijun@huawei.com>
> +L: linux-rdma@vger.kernel.org
> +S: Maintained
> +F: drivers/infiniband/hw/hisilicon/
> +F: Documentation/devicetree/bindings/infiniband/hisilicon-hns-roce.txt
> +
> SFC NETWORK DRIVER
> M: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
> M: Shradha Shah <sshah@solarflare.com>
> diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
> index 8a8440c..02eca75 100644
> --- a/drivers/infiniband/Kconfig
> +++ b/drivers/infiniband/Kconfig
> @@ -73,6 +73,7 @@ source "drivers/infiniband/hw/mlx5/Kconfig"
> source "drivers/infiniband/hw/nes/Kconfig"
> source "drivers/infiniband/hw/ocrdma/Kconfig"
> source "drivers/infiniband/hw/usnic/Kconfig"
> +source "drivers/infiniband/hw/hisilicon/hns/Kconfig"
>
> source "drivers/infiniband/ulp/ipoib/Kconfig"
>
> diff --git a/drivers/infiniband/hw/Makefile b/drivers/infiniband/hw/Makefile
> index aded2a5..ddbbf715 100644
> --- a/drivers/infiniband/hw/Makefile
> +++ b/drivers/infiniband/hw/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_MLX5_INFINIBAND) += mlx5/
> obj-$(CONFIG_INFINIBAND_NES) += nes/
> obj-$(CONFIG_INFINIBAND_OCRDMA) += ocrdma/
> obj-$(CONFIG_INFINIBAND_USNIC) += usnic/
> +obj-$(CONFIG_INFINIBAND_HISILICON_HNS) += hisilicon/hns/
> diff --git a/drivers/infiniband/hw/hisilicon/hns/Kconfig b/drivers/infiniband/hw/hisilicon/hns/Kconfig
> new file mode 100644
> index 0000000..e66e0aa
> --- /dev/null
> +++ b/drivers/infiniband/hw/hisilicon/hns/Kconfig
> @@ -0,0 +1,10 @@
> +config INFINIBAND_HISILICON_HNS
> + tristate "Hisilicon Hns ROCE Driver"
> + depends on NET_VENDOR_HISILICON
> + depends on ARM64 && HNS && HNS_DSAF && HNS_ENET
> + ---help---
> + This is a ROCE/RDMA driver for the Hisilicon RoCE engine. The engine
> + is used in Hisilicon Hi1610 and more further ICT SoC.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called roce.
"the module will be called roce" - better to call it hns-roce
> diff --git a/drivers/infiniband/hw/hisilicon/hns/Makefile b/drivers/infiniband/hw/hisilicon/hns/Makefile
> new file mode 100644
> index 0000000..bdf58ce
> --- /dev/null
> +++ b/drivers/infiniband/hw/hisilicon/hns/Makefile
> @@ -0,0 +1,9 @@
> +#
> +# Makefile for the HISILICON RoCE drivers.
> +#
> +
> +obj-$(CONFIG_INFINIBAND_HISILICON_HNS) += roce.o
> +roce-objs := hns_roce_main.o hns_roce_cmd.o hns_roce_eq.o hns_roce_pd.o \
> + hns_roce_ah.o hns_roce_icm.o hns_roce_mr.o hns_roce_qp.o \
> + hns_roce_cq.o hns_roce_alloc.o hns_roce_v1_hw.o
roce.o -> hns-roce.o
^ permalink raw reply
* Build failure in mainline kernel due to 'lan78xx: add ndo_get_stats64'
From: Guenter Roeck @ 2016-03-20 6:55 UTC (permalink / raw)
To: Woojung Huh; +Cc: David S. Miller, linux-kernel, linux-usb, netdev
Hi,
your commit a59f8c5b048 ("lan78xx: add ndo_get_stats64") is causing the
following build failure if CONFIG_PM is not enabled.
drivers/net/usb/lan78xx.c: In function 'lan78xx_get_stats64':
drivers/net/usb/lan78xx.c:3274:27: error:
'struct dev_pm_info' has no member named 'runtime_auto'
Sorry for the noise if this has already been reported.
Guenter
^ permalink raw reply
* Re: [PATCH net-next] net/mlx4_core: Fix backward compatibility on VFs
From: Yuval Shaia @ 2016-03-20 7:07 UTC (permalink / raw)
To: eli-VPRAkNaXOzVWk0Htik3J/w, David Miller
Cc: eli-VPRAkNaXOzVWk0Htik3J/w, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, aik-sLpHqDYs0B2HXe+LvDLADg
In-Reply-To: <20160318.231106.2099055485546956238.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Fri, Mar 18, 2016 at 11:11:06PM -0400, David Miller wrote:
> From: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Date: Thu, 17 Mar 2016 18:49:42 +0200
>
> > Commit 85743f1eb345 ("net/mlx4_core: Set UAR page size to 4KB regardless
> > of system page size") introduced dependency where old VF drivers without
> > this fix fail to load if the PF driver runs with this commit.
> >
> > To resolve this add a module parameter which disables that functionality
> > by default. If both the PF and VFs are running with a driver with that
> > commit the administrator may set the module param to true.
> >
> > The module parameter is called enable_4k_uar.
Can you consider passing this via comm-channel and save us all from new
module parameter?
Suggesting this from sys-admin perspective where (1) making this consist in
VF and **all** guests would me a nightmare and also (2) take into account
in public cloud that hypervisor sys-admin is not necessary the same person
as guest sys-admin.
> >
> > Fixes: 85743f1eb345 ('net/mlx4_core: Set UAR page size to 4KB ...')
> > Signed-off-by: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> Applied.
> --
> 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
--
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
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