* [PATCH net-next 0/4] mlx4 misc for 4.16
From: Tariq Toukan @ 2017-12-28 14:26 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan
Hi Dave,
This patchset contains misc cleanups and improvements
to the mlx4 Core and Eth drivers.
In patches 1 and 2 I reduce and reorder the branches in the RX csum flow.
In patch 3 I align the FMR unmapping flow with the device spec, to allow
a remapping afterwards.
Patch 4 by Moni changes the default QoS settings so that a pause
frame stops all traffic regardless of its prio.
Series generated against net-next commit:
836df24a7062 net: hns3: hns3_get_channels() can be static
Thanks,
Tariq.
Moni Shoua (1):
net/mlx4_en: Change default QoS settings
Tariq Toukan (3):
net/mlx4_en: RX csum, remove redundant branches and checks
net/mlx4_en: RX csum, reorder branches
net/mlx4_core: Cleanup FMR unmapping flow
drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c | 5 +++
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 7 ++++
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 56 +++++++++++++-------------
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 +
drivers/net/ethernet/mellanox/mlx4/mr.c | 40 +++++++++---------
5 files changed, 63 insertions(+), 46 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net-next 2/4] net/mlx4_en: RX csum, reorder branches
From: Tariq Toukan @ 2017-12-28 14:26 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan
In-Reply-To: <1514471171-3894-1-git-send-email-tariqt@mellanox.com>
Use early goto commands, and save else branches.
This uses less indentations and brackets, making the code
more readable.
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 46 ++++++++++++++----------------
1 file changed, 21 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 680bd3fbaa60..5f9dbc9a7f5b 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -816,37 +816,33 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
if (likely(dev->features & NETIF_F_RXCSUM)) {
if (cqe->status & cpu_to_be16(MLX4_CQE_STATUS_TCP |
MLX4_CQE_STATUS_UDP)) {
- if ((cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPOK)) &&
- cqe->checksum == cpu_to_be16(0xffff)) {
- bool l2_tunnel = (dev->hw_enc_features & NETIF_F_RXCSUM) &&
- (cqe->vlan_my_qpn & cpu_to_be32(MLX4_CQE_L2_TUNNEL));
-
- ip_summed = CHECKSUM_UNNECESSARY;
- hash_type = PKT_HASH_TYPE_L4;
- if (l2_tunnel)
- skb->csum_level = 1;
- ring->csum_ok++;
- } else {
+ bool l2_tunnel;
+
+ if (!((cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPOK)) &&
+ cqe->checksum == cpu_to_be16(0xffff)))
goto csum_none;
- }
+
+ l2_tunnel = (dev->hw_enc_features & NETIF_F_RXCSUM) &&
+ (cqe->vlan_my_qpn & cpu_to_be32(MLX4_CQE_L2_TUNNEL));
+ ip_summed = CHECKSUM_UNNECESSARY;
+ hash_type = PKT_HASH_TYPE_L4;
+ if (l2_tunnel)
+ skb->csum_level = 1;
+ ring->csum_ok++;
} else {
- if (priv->flags & MLX4_EN_FLAG_RX_CSUM_NON_TCP_UDP &&
- (cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPV4 |
+ if (!(priv->flags & MLX4_EN_FLAG_RX_CSUM_NON_TCP_UDP &&
+ (cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPV4 |
#if IS_ENABLED(CONFIG_IPV6)
- MLX4_CQE_STATUS_IPV6))) {
+ MLX4_CQE_STATUS_IPV6))))
#else
- 0))) {
+ 0))))
#endif
- if (check_csum(cqe, skb, va, dev->features)) {
- goto csum_none;
- } else {
- ip_summed = CHECKSUM_COMPLETE;
- hash_type = PKT_HASH_TYPE_L3;
- ring->csum_complete++;
- }
- } else {
goto csum_none;
- }
+ if (check_csum(cqe, skb, va, dev->features))
+ goto csum_none;
+ ip_summed = CHECKSUM_COMPLETE;
+ hash_type = PKT_HASH_TYPE_L3;
+ ring->csum_complete++;
}
} else {
csum_none:
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 1/4] net/mlx4_en: RX csum, remove redundant branches and checks
From: Tariq Toukan @ 2017-12-28 14:26 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan
In-Reply-To: <1514471171-3894-1-git-send-email-tariqt@mellanox.com>
Do not check IPv6 bit in cqe status if CONFIG_IPV6 is not enabled.
Function check_csum() is reached only with IPv4 or IPv6 set (if enabled),
if IPv6 is not set (or is not enabled) it is redundant to test the
IPv4 bit.
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 85e28efcda33..680bd3fbaa60 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -617,6 +617,10 @@ static int get_fixed_ipv6_csum(__wsum hw_checksum, struct sk_buff *skb,
return 0;
}
#endif
+
+/* We reach this function only after checking that any of
+ * the (IPv4 | IPv6) bits are set in cqe->status.
+ */
static int check_csum(struct mlx4_cqe *cqe, struct sk_buff *skb, void *va,
netdev_features_t dev_features)
{
@@ -632,13 +636,11 @@ static int check_csum(struct mlx4_cqe *cqe, struct sk_buff *skb, void *va,
hdr += sizeof(struct vlan_hdr);
}
- if (cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPV4))
- return get_fixed_ipv4_csum(hw_checksum, skb, hdr);
#if IS_ENABLED(CONFIG_IPV6)
if (cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPV6))
return get_fixed_ipv6_csum(hw_checksum, skb, hdr);
#endif
- return 0;
+ return get_fixed_ipv4_csum(hw_checksum, skb, hdr);
}
int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int budget)
@@ -830,7 +832,11 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
} else {
if (priv->flags & MLX4_EN_FLAG_RX_CSUM_NON_TCP_UDP &&
(cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPV4 |
+#if IS_ENABLED(CONFIG_IPV6)
MLX4_CQE_STATUS_IPV6))) {
+#else
+ 0))) {
+#endif
if (check_csum(cqe, skb, va, dev->features)) {
goto csum_none;
} else {
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 3/4] net/mlx4_core: Cleanup FMR unmapping flow
From: Tariq Toukan @ 2017-12-28 14:26 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan, Moshe Shemesh
In-Reply-To: <1514471171-3894-1-git-send-email-tariqt@mellanox.com>
Remove redundant and not essential operations in fmr unmap/free.
According to device spec, in FMR unmap it is sufficient to set
ownership bit to SW. This allows remapping afterwards.
Fixes: 8ad11fb6b073 ("IB/mlx4: Implement FMRs")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/mr.c | 40 +++++++++++++++++----------------
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mr.c b/drivers/net/ethernet/mellanox/mlx4/mr.c
index c7c0764991c9..2e84f10f59ba 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mr.c
+++ b/drivers/net/ethernet/mellanox/mlx4/mr.c
@@ -1103,30 +1103,16 @@ int mlx4_fmr_enable(struct mlx4_dev *dev, struct mlx4_fmr *fmr)
void mlx4_fmr_unmap(struct mlx4_dev *dev, struct mlx4_fmr *fmr,
u32 *lkey, u32 *rkey)
{
- struct mlx4_cmd_mailbox *mailbox;
- int err;
-
if (!fmr->maps)
return;
- fmr->maps = 0;
+ /* To unmap: it is sufficient to take back ownership from HW */
+ *(u8 *)fmr->mpt = MLX4_MPT_STATUS_SW;
- mailbox = mlx4_alloc_cmd_mailbox(dev);
- if (IS_ERR(mailbox)) {
- err = PTR_ERR(mailbox);
- pr_warn("mlx4_ib: mlx4_alloc_cmd_mailbox failed (%d)\n", err);
- return;
- }
+ /* Make sure MPT status is visible */
+ wmb();
- err = mlx4_HW2SW_MPT(dev, NULL,
- key_to_hw_index(fmr->mr.key) &
- (dev->caps.num_mpts - 1));
- mlx4_free_cmd_mailbox(dev, mailbox);
- if (err) {
- pr_warn("mlx4_ib: mlx4_HW2SW_MPT failed (%d)\n", err);
- return;
- }
- fmr->mr.enabled = MLX4_MPT_EN_SW;
+ fmr->maps = 0;
}
EXPORT_SYMBOL_GPL(mlx4_fmr_unmap);
@@ -1136,6 +1122,22 @@ int mlx4_fmr_free(struct mlx4_dev *dev, struct mlx4_fmr *fmr)
if (fmr->maps)
return -EBUSY;
+ if (fmr->mr.enabled == MLX4_MPT_EN_HW) {
+ /* In case of FMR was enabled and unmapped
+ * make sure to give ownership of MPT back to HW
+ * so HW2SW_MPT command will success.
+ */
+ *(u8 *)fmr->mpt = MLX4_MPT_STATUS_SW;
+ /* Make sure MPT status is visible before changing MPT fields */
+ wmb();
+ fmr->mpt->length = 0;
+ fmr->mpt->start = 0;
+ /* Make sure MPT data is visible after changing MPT status */
+ wmb();
+ *(u8 *)fmr->mpt = MLX4_MPT_STATUS_HW;
+ /* make sure MPT status is visible */
+ wmb();
+ }
ret = mlx4_mr_free(dev, &fmr->mr);
if (ret)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 4/4] net/mlx4_en: Change default QoS settings
From: Tariq Toukan @ 2017-12-28 14:26 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Eran Ben Elisha, Moni Shoua, Maor Gottlieb, Tariq Toukan
In-Reply-To: <1514471171-3894-1-git-send-email-tariqt@mellanox.com>
From: Moni Shoua <monis@mellanox.com>
Change the default mapping between TC and TCG as follows:
Prio | TC/TCG
| from to
| (set by FW) (set by SW)
---------+-----------------------------------
0 | 0/0 0/7
1 | 1/0 0/6
2 | 2/0 0/5
3 | 3/0 0/4
4 | 4/0 0/3
5 | 5/0 0/2
6 | 6/0 0/1
7 | 7/0 0/0
These new settings cause that a pause frame for any prio stops
traffic for all prios.
Fixes: 564c274c3df0 ("net/mlx4_en: DCB QoS support")
Signed-off-by: Moni Shoua <monis@mellanox.com>
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c | 5 +++++
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 7 +++++++
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 +
3 files changed, 13 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c b/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
index 5f41dc92aa68..1a0c3bf86ead 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
@@ -310,6 +310,7 @@ static int mlx4_en_ets_validate(struct mlx4_en_priv *priv, struct ieee_ets *ets)
}
switch (ets->tc_tsa[i]) {
+ case IEEE_8021QAZ_TSA_VENDOR:
case IEEE_8021QAZ_TSA_STRICT:
break;
case IEEE_8021QAZ_TSA_ETS:
@@ -347,6 +348,10 @@ static int mlx4_en_config_port_scheduler(struct mlx4_en_priv *priv,
/* higher TC means higher priority => lower pg */
for (i = IEEE_8021QAZ_MAX_TCS - 1; i >= 0; i--) {
switch (ets->tc_tsa[i]) {
+ case IEEE_8021QAZ_TSA_VENDOR:
+ pg[i] = MLX4_EN_TC_VENDOR;
+ tc_tx_bw[i] = MLX4_EN_BW_MAX;
+ break;
case IEEE_8021QAZ_TSA_STRICT:
pg[i] = num_strict++;
tc_tx_bw[i] = MLX4_EN_BW_MAX;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 99051a294fa6..21bc17fa3854 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -3336,6 +3336,13 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
priv->msg_enable = MLX4_EN_MSG_LEVEL;
#ifdef CONFIG_MLX4_EN_DCB
if (!mlx4_is_slave(priv->mdev->dev)) {
+ u8 prio;
+
+ for (prio = 0; prio < IEEE_8021QAZ_MAX_TCS; ++prio) {
+ priv->ets.prio_tc[prio] = prio;
+ priv->ets.tc_tsa[prio] = IEEE_8021QAZ_TSA_VENDOR;
+ }
+
priv->dcbx_cap = DCB_CAP_DCBX_VER_CEE | DCB_CAP_DCBX_HOST |
DCB_CAP_DCBX_VER_IEEE;
priv->flags |= MLX4_EN_DCB_ENABLED;
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 2b72677eccd4..7db3d0d9bfce 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -479,6 +479,7 @@ struct mlx4_en_frag_info {
#define MLX4_EN_BW_MIN 1
#define MLX4_EN_BW_MAX 100 /* Utilize 100% of the line */
+#define MLX4_EN_TC_VENDOR 0
#define MLX4_EN_TC_ETS 7
enum dcb_pfc_type {
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Florian Fainelli @ 2017-12-28 15:02 UTC (permalink / raw)
To: Antoine Tenart, Andrew Lunn
Cc: thomas.petazzoni, ymarkman, jason, netdev, linux-kernel,
Russell King - ARM Linux, kishon, nadavh, miquel.raynal,
gregory.clement, stefanc, mw, davem, linux-arm-kernel,
sebastian.hesselbarth
In-Reply-To: <20171228100519.GE2626@kwain>
On 12/28/2017 02:05 AM, Antoine Tenart wrote:
> Hi Andrew,
>
> On Thu, Dec 28, 2017 at 08:46:23AM +0100, Andrew Lunn wrote:
>> On Wed, Dec 27, 2017 at 10:24:01PM +0000, Russell King - ARM Linux wrote:
>>> On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote:
>>>>
>>>> +&cps_eth2 {
>>>> + /* CPS Lane 5 */
>>>> + status = "okay";
>>>> + phy-mode = "2500base-x";
>>>> + /* Generic PHY, providing serdes lanes */
>>>> + phys = <&cps_comphy5 2>;
>>>> +};
>>>> +
>>>
>>> This is wrong. This lane is connected to a SFP cage which can support
>>> more than just 2500base-X. Tying it in this way to 2500base-X means
>>> that this port does not support conenctions at 1000base-X, despite
>>> that's one of the most popular and more standardised speeds.
>>>
>>
>> I agree with Russell here. SFP modules are hot pluggable, and support
>> a range of interface modes. You need to query what the SFP module is
>> in order to know how to configure the SERDES interface. The phylink
>> infrastructure does that for you.
>
> Sure, I understand. We'll be able to support such interfaces only when
> the phylink PPv2 support lands in.
Should we expect PHYLINK support to make it as the first patch in your
v2 of this patch series, or is someone else doing that?
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 2/2] l2tp: add peer_offset parameter
From: Guillaume Nault @ 2017-12-28 14:53 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: davem, netdev, jchapman, liuhangbin
In-Reply-To: <d51dc65a40c5e335984e95a1e6db0eea00d9fd13.1513951129.git.lorenzo.bianconi@redhat.com>
On Fri, Dec 22, 2017 at 03:10:18PM +0100, Lorenzo Bianconi wrote:
> Introduce peer_offset parameter in order to add the capability
> to specify two different values for payload offset on tx/rx side.
> If just offset is provided by userspace use it for rx side as well
> in order to maintain compatibility with older l2tp versions
>
Sorry for being late on this, I originally missed this patchset and
only noticed it yesterday.
Lorenzo, can you give some context around this new feature?
Quite frankly I can't see the point of it. I've never heard of offsets
in L2TPv3, and for L2TPv2, the offset value is already encoded in the
header.
After a quick review of L2TPv3 and pseudowires RFCs, I still don't see
how adding some padding between the L2TPv3 header and the payload could
constitute a valid frame. Of course, the base feature is already there,
but after a quick test, it looks like the padding bits aren't
initialised and leak memory.
So, unless I missed something, setting offsets in L2TPv3 is
non-compliant, the current implementation is buggy and most likely
unused. I'd really prefer getting the implementation fixed, or even
removed entirely. Extending it to allow asymmetrical offset values
looks wrong to me, unless you have a use case in mind.
Regards,
Guillaume
PS: I also noticed that iproute2 has a "peer_offset" option, but it's a
noop.
^ permalink raw reply
* Re: [PATCH iproute2] gre/tunnel: Print erspan_index using print_uint()
From: William Tu @ 2017-12-28 15:13 UTC (permalink / raw)
To: Serhey Popovych; +Cc: Linux Kernel Network Developers
In-Reply-To: <1514459579-20379-1-git-send-email-serhe.popovych@gmail.com>
Hi Serhey,
On Thu, Dec 28, 2017 at 3:12 AM, Serhey Popovych
<serhe.popovych@gmail.com> wrote:
> One is missing in JSON output because fprintf()
> is used instead of print_uint().
>
> Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
> ---
> ip/link_gre.c | 3 ++-
> ip/link_gre6.c | 4 +++-
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/ip/link_gre.c b/ip/link_gre.c
> index 896bb19..1e331c8 100644
> --- a/ip/link_gre.c
> +++ b/ip/link_gre.c
> @@ -476,7 +476,8 @@ static void gre_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
> if (tb[IFLA_GRE_ERSPAN_INDEX]) {
> __u32 erspan_idx = rta_getattr_u32(tb[IFLA_GRE_ERSPAN_INDEX]);
>
> - fprintf(f, "erspan_index %u ", erspan_idx);
> + print_uint(PRINT_ANY,
> + "erspan_index", "erspan_index %u ", erspan_idx);
> }
>
Did you pull the latest code from net-next branch?
I think I already fix it.
William
^ permalink raw reply
* Re: [PATCH iproute2] gre/tunnel: Print erspan_index using print_uint()
From: Serhey Popovych @ 2017-12-28 15:48 UTC (permalink / raw)
To: William Tu; +Cc: Linux Kernel Network Developers
In-Reply-To: <CALDO+SYhqzg=rewp0qRBOLdz8r7QdN_aORHpz1o02PMiTcWiUQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1450 bytes --]
> Hi Serhey,
Hi William,
Yes, iproute2-next/net-next branch contains fix already: we probably do
not need proposed change. Sorry for noise.
I'm currently focused on bug fixing in stable which affects my work for
iproute2-next. All my future work will be based on iproute2-next as it
contains refactoring, optimization and cleanups, not fixes.
Sorry again and thanks for feedback.
>
> On Thu, Dec 28, 2017 at 3:12 AM, Serhey Popovych
> <serhe.popovych@gmail.com> wrote:
>> One is missing in JSON output because fprintf()
>> is used instead of print_uint().
>>
>> Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
>> ---
>> ip/link_gre.c | 3 ++-
>> ip/link_gre6.c | 4 +++-
>> 2 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/ip/link_gre.c b/ip/link_gre.c
>> index 896bb19..1e331c8 100644
>> --- a/ip/link_gre.c
>> +++ b/ip/link_gre.c
>> @@ -476,7 +476,8 @@ static void gre_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
>> if (tb[IFLA_GRE_ERSPAN_INDEX]) {
>> __u32 erspan_idx = rta_getattr_u32(tb[IFLA_GRE_ERSPAN_INDEX]);
>>
>> - fprintf(f, "erspan_index %u ", erspan_idx);
>> + print_uint(PRINT_ANY,
>> + "erspan_index", "erspan_index %u ", erspan_idx);
>> }
>>
>
> Did you pull the latest code from net-next branch?
> I think I already fix it.
> William
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [patch net-next] net: sched: don't set extack message in case the qdisc will be created
From: Jiri Pirko @ 2017-12-28 15:52 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, mlxsw, aring
From: Jiri Pirko <jiri@mellanox.com>
If the qdisc is not found here, it is going to be created. Therefore,
this is not an error path. Remove the extack message set and don't
confuse user with error message in case the qdisc was created
successfully.
Fixes: 09215598119e ("net: sched: sch_api: handle generic qdisc errors")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/sch_api.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index 3a3a1da..81ecf5b 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -1402,10 +1402,8 @@ static int tc_modify_qdisc(struct sk_buff *skb, struct nlmsghdr *n,
return -EINVAL;
}
q = qdisc_lookup(dev, tcm->tcm_handle);
- if (!q) {
- NL_SET_ERR_MSG(extack, "No qdisc found for specified handle");
+ if (!q)
goto create_n_graft;
- }
if (n->nlmsg_flags & NLM_F_EXCL) {
NL_SET_ERR_MSG(extack, "Exclusivity flag on, cannot override");
return -EEXIST;
--
2.9.5
^ permalink raw reply related
* Re: [PATCH net-next v2 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor
From: Jason Baron @ 2017-12-28 15:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, virtualization, qemu-devel, mst, jasowang
In-Reply-To: <20171227.164334.2079471466039224265.davem@davemloft.net>
On 12/27/2017 04:43 PM, David Miller wrote:
> From: Jason Baron <jbaron@akamai.com>
> Date: Fri, 22 Dec 2017 16:54:01 -0500
>
>> The ability to set speed and duplex for virtio_net in useful in various
>> scenarios as described here:
>>
>> 16032be virtio_net: add ethtool support for set and get of settings
>>
>> However, it would be nice to be able to set this from the hypervisor,
>> such that virtio_net doesn't require custom guest ethtool commands.
>>
>> Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows
>> the hypervisor to export a linkspeed and duplex setting. The user can
>> subsequently overwrite it later if desired via: 'ethtool -s'.
>>
>> Signed-off-by: Jason Baron <jbaron@akamai.com>
>> Cc: "Michael S. Tsirkin" <mst@redhat.com>
>> Cc: Jason Wang <jasowang@redhat.com>
>
> Looks mostly fine to me but need some virtio_net reviewers on this one.
>
>> @@ -57,6 +57,8 @@
>> * Steering */
>> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
>>
>> +#define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Host set linkspeed and duplex */
>> +
>
> Why use a value so far away from the largest existing one?
>
> Just curious.
>
So that came from a discussion with Michael about which bit to use for
this, and he suggested using 63:
"
Transports started from bit 24 and are growing up.
So I would say devices should start from bit 63 and grow down.
"
https://patchwork.ozlabs.org/patch/848814/#1826669
I will add a comment to explain it.
Thanks,
-Jason
^ permalink raw reply
* SPECIAL OFFER !!!
From: Abdul Halima @ 2017-12-28 16:08 UTC (permalink / raw)
Do you need a Loan if the answer is yes kindly contact us for more
information: lenderroyal0@gmail.com
^ permalink raw reply
* Re: [patch net-next v2 00/10] Add support for resource abstraction
From: David Ahern @ 2017-12-28 16:09 UTC (permalink / raw)
To: Yuval Mintz, Jiri Pirko
Cc: netdev@vger.kernel.org, davem@davemloft.net, Arkadi Sharshevsky,
mlxsw, andrew@lunn.ch, vivien.didelot@savoirfairelinux.com,
f.fainelli@gmail.com, michael.chan@broadcom.com,
ganeshgr@chelsio.com, Saeed Mahameed, Matan Barak,
Leon Romanovsky, Ido Schimmel, jakub.kicinski@netronome.com,
ast@kernel.org, daniel@iogearbox.net, simon.horman@netronome.com
In-Reply-To: <VI1PR05MB35206F8E7CB725188F9F509EBF040@VI1PR05MB3520.eurprd05.prod.outlook.com>
On 12/28/17 2:25 AM, Yuval Mintz wrote:
>>>> Again, I have no objections to kvd, linear, hash, etc terms as they do
>>>> relate to Mellanox products. But kvd/linear, for example, does correlate
>>>> to industry standard concepts in some way. My request is that the
>>>> resource listing guide the user in some way, stating what these
>>>> resources mean.
>>>
>>> So the showed relation to dpipe table would be enougn or you would still
>>> like to see some description? I don't like the description concept here
>>> as the relations to dpipe table should tell user exactly what he needs
>>> to know.
>>
>> I believe it is useful to have a 1-line, short description that gives
>> the user some memory jogger as to what the resource is used for. It does
>> not have to be an exhaustive list, but the user should not have to do
>> mental jumping jacks running a bunch of commands to understand the
>> resources for vendor specific asics.
>
> Perhaps we can simply have devlink utility output the dpipe
> table[s] associated with the resource when showing the resource?
> It would contain live information as well as prevent the need for
> 'mental jumping jacks'.
>
My primary contention for this static partitioning is that the proposal
is not giving the user the information they need to make decisions.
As I mentioned earlier, the resource show command gives this:
$ devlink resource show pci/0000:03:00.0
pci/0000:03:00.0:
name kvd size 245760 size_valid true
resources:
name linear size 98304 occ 0
name hash_double size 60416
name hash_single size 87040
the paths /kvd/linear, /kvd/hash_single and /kvd/hash_double are
essentially random names (nothing related to industry standard names)
and the listed sizes are random numbers (no units)[1]. There is nothing
there to tell a user what they can adjust or why they would want to make
an adjustment.
Looking at 'dpipe table show':
$ devlink dpipe table show pci/0000:03:00.0
pci/0000:03:00.0:
name mlxsw_erif size 1000 counters_enabled false
match:
type field_exact header mlxsw_meta field erif_port mapping ifindex
action:
type field_modify header mlxsw_meta field l3_forward
type field_modify header mlxsw_meta field l3_drop
resource_path /kvd/hash_single name mlxsw_host4 size 62
counters_enabled false
match:
type field_exact header mlxsw_meta field erif_port mapping ifindex
type field_exact header ipv4 field destination ip
action:
type field_modify header ethernet field destination mac
resource_path /kvd/hash_double name mlxsw_host6 size 0
counters_enabled false
match:
type field_exact header mlxsw_meta field erif_port mapping ifindex
type field_exact header ipv6 field destination ip
action:
type field_modify header ethernet field destination mac
resource_path /kvd/linear name mlxsw_adj size 0 counters_enabled false
match:
type field_exact header mlxsw_meta field adj_index
type field_exact header mlxsw_meta field adj_size
type field_exact header mlxsw_meta field adj_hash_index
action:
type field_modify header ethernet field destination mac
type field_modify header mlxsw_meta field erif_port mapping ifindex
So there are 4 tables exported to userspace:
1. mlxsw_erif table which is not in any of the kvd regions (no resource
path is given) and it has a size of 1000. Does mlxsw_erif mean a rif as
in Router Interfaces? So the switch supports up to 1000 router interfaces.
2. mlxsw_host4 in /kvd/hash_single with a size of 62. Based on the
fields mlxsw_host4 means IPv4 host entries (neighbor entries). Why is
the size set at 62? Seems really low.
3. mlxsw_host6 in /kvd/hash_double with a size of 0. Based on the fields
mlxsw_host6 means IPv6 host entries (neighbor entries). The size of 0 is
concerning. I guess the switch is not configured to do IPv6?
4. mlxsw_adj in /kvd/linear with a size of 0. Based on the fields I am
going to guess it is an fdb entry????
So if I combine the output of "resource show" and "dpipe table show", I
can conclude:
1. /kvd/linear is only used for fdb entries. So if I want an L3 only use
case I can set /kvd/linear 0. Is that correct? I believe the answer is
no, but based on the information given it seems that way.
2. /kvd/hash_double has a size of 60416, but it is only used for
mlxsw_host6 table which has a size of 0. Now, I am confused.
3. /kvd/hash_single has a size of 87040, but it is only used for
mlxsw_host4 table which has a size of 62. Again confused.
What is a user to make of this output? How is it useful for making
decisions on whether to increase or decrease some resource?
----
[1] In a response, Jiri mentioned units are added by this patch set but
all I see in the patches is this:
@@ -245,4 +256,8 @@ enum devlink_dpipe_header_id {
DEVLINK_DPIPE_HEADER_IPV6,
};
+enum devlink_resource_unit {
+ DEVLINK_RESOURCE_UNIT_DOUBLE_WORD,
+};
+
#endif /* _UAPI_LINUX_DEVLINK_H_ */
DEVLINK_RESOURCE_UNIT_DOUBLE_WORD means what???
^ permalink raw reply
* Re: WARNING in strp_data_ready
From: Tom Herbert @ 2017-12-28 16:14 UTC (permalink / raw)
To: Ozgur
Cc: Dmitry Vyukov, John Fastabend, syzbot, David S. Miller,
Eric Biggers, LKML, Linux Kernel Network Developers,
syzkaller-bugs@googlegroups.com, Tom Herbert, Cong Wang
In-Reply-To: <297161514451589@web50o.yandex.ru>
On Thu, Dec 28, 2017 at 12:59 AM, Ozgur <ozgur@goosey.org> wrote:
>
>
> 28.12.2017, 04:19, "Tom Herbert" <tom@herbertland.com>:
>> On Wed, Dec 27, 2017 at 12:20 PM, Ozgur <ozgur@goosey.org> wrote:
>>> 27.12.2017, 23:14, "Dmitry Vyukov" <dvyukov@google.com>:
>>>> On Wed, Dec 27, 2017 at 9:08 PM, Ozgur <ozgur@goosey.org> wrote:
>>>>> 27.12.2017, 22:21, "Dmitry Vyukov" <dvyukov@google.com>:
>>>>>> On Wed, Dec 27, 2017 at 8:09 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>>> Did you try the patch I posted?
>>>>>>
>>>>>> Hi Tom,
>>>>>
>>>>> Hello Dmitry,
>>>>>
>>>>>> No. And I didn't know I need to. Why?
>>>>>> If you think the patch needs additional testing, you can ask syzbot to
>>>>>> test it. See https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot
>>>>>> Otherwise proceed with committing it. Or what are we waiting for?
>>>>>>
>>>>>> Thanks
>>>>>
>>>>> I think we need to fixed patch for crash, in fact check to patch code and test solve the bug.
>>>>> How do test it because there is no patch in the following bug?
>>>>
>>>> Hi Ozgur,
>>>>
>>>> I am not sure I completely understand what you mean. But the
>>>> reproducer for this bug (which one can use for testing) is here:
>>>> https://groups.google.com/forum/#!topic/syzkaller-bugs/Kxs05ziCpgY
>>>> Tom also mentions there is some patch for this, but I don't know where
>>>> it is, it doesn't seem to be referenced from this thread.
>>>
>>> Hello Dmitry,
>>>
>>> Ah, I'm sorry I don't seen Tom mail and I don't have a patch not tested :)
>>> I think Tom send patch to only you and are you tested?
>>>
>>> kcmsock.c will change and strp_data_ready I think locked.
>>>
>>> Tom, please send a patch for me? I can test and inform you.
>>
>> Hi Ozgur,
>>
>> I reposted the patches as RFC "kcm: Fix lockdep issue". Please test if you can!
>>
>> Thanks,
>> Tom
>
> Hello Tom,
>
> Which are you use the repos? I pulled but I don't seen this patches.
>
They are not in any public repo yet. I posted the patches to netdev
list so they can be reviewed and tested by third parties. Posting
patches to the list a normal path to get patches into the kernel
(http://nickdesaulniers.github.io/blog/2017/05/16/submitting-your-first-patch-to-the-linux-kernel-and-responding-to-feedback/).
These patches were applied to net-next but are simple enough that they
should apply to other branches. I will repost and target to net per
Dave's directive once they are verified to fix the issue.
Tom
^ permalink raw reply
* Re: [RFT net-next v2 0/3] dwmac-meson8b: RGMII clock fixes for Meson8b
From: Emiliano Ingrassia @ 2017-12-28 16:16 UTC (permalink / raw)
To: Martin Blumenstingl, netdev
Cc: linus.luessing, khilman, linux-amlogic, jbrunet, narmstrong,
peppe.cavallaro, alexandre.torgue
In-Reply-To: <20171223234100.11814-1-martin.blumenstingl@googlemail.com>
Hi Martin, Hi Dave,
On Sun, Dec 24, 2017 at 12:40:57AM +0100, Martin Blumenstingl wrote:
> Hi Dave,
>
> please do not apply this series until it got a Tested-by from Emiliano.
>
>
> Hi Emiliano,
>
> you reported [0] that you couldn't get dwmac-meson8b to work on your
> Odroid-C1. With your findings (register dumps, clk_summary output, etc.)
> I think I was able to find a fix: it consists of two patches (which you
> find in this series)
>
> Unfortunately I don't have any Meson8b boards with RGMII PHY so I could
> only partially test this (I could only check if the clocks were
> calculated correctly when using a dummy 500002394Hz input clock instead
> of MPLL2).
>
> Could you please give this series a try and let me know about the
> results?
> You obviously still need your two "ARM: dts: meson8b" patches which
> - add the amlogic,meson8b-dwmac" compatible to meson8b.dtsi
> - enable Ethernet on the Odroid-C1
>
> I have tested this myself on a Khadas VIM (GXL SoC, internal RMII PHY)
> and a Khadas VIM2 (GXM SoC, external RGMII PHY). Both are still working
> fine (so let's hope that this also fixes your Meson8b issue :)).
>
>
> changes since v1 at [1]:
> - changed the subject of the cover-letter to indicate that this is all
> about the RGMII clock
> - added PATCH #1 which ensures that we don't unnecessarily change the
> parent clocks in RMII mode (and also makes the code easier to
> understand)
> - changed subject of PATCH #2 (formerly PATCH #1) to state that this
> is about the RGMII clock
> - added Jerome's Reviewed-by to PATCH #2 (formerly PATCH #1)
> - replaced PATCH #3 (formerly PATCH #2) with one that sets
> CLK_SET_RATE_PARENT on the mux and thus re-configures the MPLL2 clock
> on Meson8b correctly
>
Really thank you for your help and effort. I tried your patch but
unfortunately it didn't solve the problem.
Here is the new clk_summary:
xtal 1 1 24000000 0 0
sys_pll 0 0 1200000000 0 0
cpu_clk 0 0 1200000000 0 0
vid_pll 0 0 732000000 0 0
fixed_pll 2 2 2550000000 0 0
mpll2 1 1 106250000 0 0
c9410000.ethernet#m250_sel 1 1 106250000 0 0
c9410000.ethernet#m250_div 1 1 106250000 0 0
c9410000.ethernet#m25_div 1 1 21250000 0 0
which leads to a value of 0x70a1 in the prg0 ethernet register.
As you can see, something is changed but the RGMII clock is not at 25 MHz.
In particular, the bit 10 of prg0, which enables the "generation of 25 MHz
clock for PHY" (see S805 manual), is 0.
Please, if you have other suggestions let me know.
Best regards,
Emiliano
>
> [0] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005596.html
> [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005848.html
>
>
> Martin Blumenstingl (3):
> net: stmmac: dwmac-meson8b: only configure the clocks in RGMII mode
> net: stmmac: dwmac-meson8b: fix setting the RGMII clock on Meson8b
> net: stmmac: dwmac-meson8b: propagate rate changes to the parent clock
>
> .../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 55 +++++++++++-----------
> 1 file changed, 27 insertions(+), 28 deletions(-)
>
> --
> 2.15.1
>
^ permalink raw reply
* Re: [patch net-next v2 00/10] Add support for resource abstraction
From: Jiri Pirko @ 2017-12-28 16:23 UTC (permalink / raw)
To: David Ahern
Cc: Yuval Mintz, netdev@vger.kernel.org, davem@davemloft.net,
Arkadi Sharshevsky, mlxsw, andrew@lunn.ch,
vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,
michael.chan@broadcom.com, ganeshgr@chelsio.com, Saeed Mahameed,
Matan Barak, Leon Romanovsky, Ido Schimmel,
jakub.kicinski@netronome.com, ast@kernel.org,
daniel@iogearbox.net, "
In-Reply-To: <22cc777b-e39e-29c0-22fe-aa7a99ef80df@cumulusnetworks.com>
Thu, Dec 28, 2017 at 05:09:09PM CET, dsa@cumulusnetworks.com wrote:
>On 12/28/17 2:25 AM, Yuval Mintz wrote:
>>>>> Again, I have no objections to kvd, linear, hash, etc terms as they do
>>>>> relate to Mellanox products. But kvd/linear, for example, does correlate
>>>>> to industry standard concepts in some way. My request is that the
>>>>> resource listing guide the user in some way, stating what these
>>>>> resources mean.
>>>>
>>>> So the showed relation to dpipe table would be enougn or you would still
>>>> like to see some description? I don't like the description concept here
>>>> as the relations to dpipe table should tell user exactly what he needs
>>>> to know.
>>>
>>> I believe it is useful to have a 1-line, short description that gives
>>> the user some memory jogger as to what the resource is used for. It does
>>> not have to be an exhaustive list, but the user should not have to do
>>> mental jumping jacks running a bunch of commands to understand the
>>> resources for vendor specific asics.
>>
>> Perhaps we can simply have devlink utility output the dpipe
>> table[s] associated with the resource when showing the resource?
>> It would contain live information as well as prevent the need for
>> 'mental jumping jacks'.
>>
>
>My primary contention for this static partitioning is that the proposal
>is not giving the user the information they need to make decisions.
>
>As I mentioned earlier, the resource show command gives this:
>$ devlink resource show pci/0000:03:00.0
>pci/0000:03:00.0:
> name kvd size 245760 size_valid true
> resources:
> name linear size 98304 occ 0
> name hash_double size 60416
> name hash_single size 87040
>
>the paths /kvd/linear, /kvd/hash_single and /kvd/hash_double are
>essentially random names (nothing related to industry standard names)
Of course. There is no industry standard for internal ASIC
implementations. This is the same as for dpipe. There is no industry
standard for ASIC pipeline. dpipe visualizes it. This resource patch
visualizes the internal ASIC resources and their mapping to the
individual dpipe tables.
>and the listed sizes are random numbers (no units)[1]. There is nothing
>there to tell a user what they can adjust or why they would want to make
>an adjustment.
>
>
>Looking at 'dpipe table show':
>
>$ devlink dpipe table show pci/0000:03:00.0
>pci/0000:03:00.0:
> name mlxsw_erif size 1000 counters_enabled false
> match:
> type field_exact header mlxsw_meta field erif_port mapping ifindex
> action:
> type field_modify header mlxsw_meta field l3_forward
> type field_modify header mlxsw_meta field l3_drop
>
> resource_path /kvd/hash_single name mlxsw_host4 size 62
>counters_enabled false
> match:
> type field_exact header mlxsw_meta field erif_port mapping ifindex
> type field_exact header ipv4 field destination ip
> action:
> type field_modify header ethernet field destination mac
>
> resource_path /kvd/hash_double name mlxsw_host6 size 0
>counters_enabled false
> match:
> type field_exact header mlxsw_meta field erif_port mapping ifindex
> type field_exact header ipv6 field destination ip
> action:
> type field_modify header ethernet field destination mac
>
> resource_path /kvd/linear name mlxsw_adj size 0 counters_enabled false
> match:
> type field_exact header mlxsw_meta field adj_index
> type field_exact header mlxsw_meta field adj_size
> type field_exact header mlxsw_meta field adj_hash_index
> action:
> type field_modify header ethernet field destination mac
> type field_modify header mlxsw_meta field erif_port mapping ifindex
>
>
>So there are 4 tables exported to userspace:
>
>1. mlxsw_erif table which is not in any of the kvd regions (no resource
>path is given) and it has a size of 1000. Does mlxsw_erif mean a rif as
>in Router Interfaces? So the switch supports up to 1000 router interfaces.
>
>2. mlxsw_host4 in /kvd/hash_single with a size of 62. Based on the
Size tells you the actual size. It cannot give you max size. The reason
is simple. The resources are shared among multiple tables. That is
exactly what this resource patch makes visible.
>fields mlxsw_host4 means IPv4 host entries (neighbor entries). Why is
>the size set at 62? Seems really low.
>
>3. mlxsw_host6 in /kvd/hash_double with a size of 0. Based on the fields
>mlxsw_host6 means IPv6 host entries (neighbor entries). The size of 0 is
>concerning. I guess the switch is not configured to do IPv6?
>
>4. mlxsw_adj in /kvd/linear with a size of 0. Based on the fields I am
>going to guess it is an fdb entry????
^ permalink raw reply
* Re: WARNING in strp_data_ready
From: Dmitry Vyukov @ 2017-12-28 16:33 UTC (permalink / raw)
To: Tom Herbert
Cc: Ozgur, John Fastabend, syzbot, David S. Miller, Eric Biggers,
LKML, Linux Kernel Network Developers,
syzkaller-bugs@googlegroups.com, Tom Herbert, Cong Wang
In-Reply-To: <CALx6S36HESpYXAtz+EdiFr5UGD2hs2BtXA8i65GVPbTiuamfRA@mail.gmail.com>
On Thu, Dec 28, 2017 at 5:14 PM, Tom Herbert <tom@herbertland.com> wrote:
> On Thu, Dec 28, 2017 at 12:59 AM, Ozgur <ozgur@goosey.org> wrote:
>>
>>
>> 28.12.2017, 04:19, "Tom Herbert" <tom@herbertland.com>:
>>> On Wed, Dec 27, 2017 at 12:20 PM, Ozgur <ozgur@goosey.org> wrote:
>>>> 27.12.2017, 23:14, "Dmitry Vyukov" <dvyukov@google.com>:
>>>>> On Wed, Dec 27, 2017 at 9:08 PM, Ozgur <ozgur@goosey.org> wrote:
>>>>>> 27.12.2017, 22:21, "Dmitry Vyukov" <dvyukov@google.com>:
>>>>>>> On Wed, Dec 27, 2017 at 8:09 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>>>> Did you try the patch I posted?
>>>>>>>
>>>>>>> Hi Tom,
>>>>>>
>>>>>> Hello Dmitry,
>>>>>>
>>>>>>> No. And I didn't know I need to. Why?
>>>>>>> If you think the patch needs additional testing, you can ask syzbot to
>>>>>>> test it. See https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot
>>>>>>> Otherwise proceed with committing it. Or what are we waiting for?
>>>>>>>
>>>>>>> Thanks
>>>>>>
>>>>>> I think we need to fixed patch for crash, in fact check to patch code and test solve the bug.
>>>>>> How do test it because there is no patch in the following bug?
>>>>>
>>>>> Hi Ozgur,
>>>>>
>>>>> I am not sure I completely understand what you mean. But the
>>>>> reproducer for this bug (which one can use for testing) is here:
>>>>> https://groups.google.com/forum/#!topic/syzkaller-bugs/Kxs05ziCpgY
>>>>> Tom also mentions there is some patch for this, but I don't know where
>>>>> it is, it doesn't seem to be referenced from this thread.
>>>>
>>>> Hello Dmitry,
>>>>
>>>> Ah, I'm sorry I don't seen Tom mail and I don't have a patch not tested :)
>>>> I think Tom send patch to only you and are you tested?
>>>>
>>>> kcmsock.c will change and strp_data_ready I think locked.
>>>>
>>>> Tom, please send a patch for me? I can test and inform you.
>>>
>>> Hi Ozgur,
>>>
>>> I reposted the patches as RFC "kcm: Fix lockdep issue". Please test if you can!
>>>
>>> Thanks,
>>> Tom
>>
>> Hello Tom,
>>
>> Which are you use the repos? I pulled but I don't seen this patches.
>>
> They are not in any public repo yet. I posted the patches to netdev
> list so they can be reviewed and tested by third parties. Posting
> patches to the list a normal path to get patches into the kernel
> (http://nickdesaulniers.github.io/blog/2017/05/16/submitting-your-first-patch-to-the-linux-kernel-and-responding-to-feedback/).
>
> These patches were applied to net-next but are simple enough that they
> should apply to other branches. I will repost and target to net per
> Dave's directive once they are verified to fix the issue.
FWIW they are already verified to fix the issue, see few emails up, also here:
https://groups.google.com/d/msg/syzkaller-bugs/Kxs05ziCpgY/fPdZcO_GAwAJ
and don't forget this:
https://groups.google.com/d/msg/syzkaller-bugs/Kxs05ziCpgY/uGjsrA3HAwAJ
^ permalink raw reply
* Re: [patch net-next v2 00/10] Add support for resource abstraction
From: David Ahern @ 2017-12-28 16:33 UTC (permalink / raw)
To: Jiri Pirko
Cc: Yuval Mintz, netdev@vger.kernel.org, davem@davemloft.net,
Arkadi Sharshevsky, mlxsw, andrew@lunn.ch,
vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,
michael.chan@broadcom.com, ganeshgr@chelsio.com, Saeed Mahameed,
Matan Barak, Leon Romanovsky, Ido Schimmel,
jakub.kicinski@netronome.com, ast@kernel.org,
daniel@iogearbox.net, "
In-Reply-To: <20171228162314.GA1983@nanopsycho>
On 12/28/17 10:23 AM, Jiri Pirko wrote:
>> So there are 4 tables exported to userspace:
>>
>> 1. mlxsw_erif table which is not in any of the kvd regions (no resource
>> path is given) and it has a size of 1000. Does mlxsw_erif mean a rif as
>> in Router Interfaces? So the switch supports up to 1000 router interfaces.
>>
>> 2. mlxsw_host4 in /kvd/hash_single with a size of 62. Based on the
> Size tells you the actual size. It cannot give you max size. The reason
> is simple. The resources are shared among multiple tables. That is
> exactly what this resource patch makes visible.
>
>
In the erif table, the 1000 is the max not current usage. I do not have
1000 interfaces:
$ ip -br li sh | wc -l
597
$ devlink dpipe table dump pci/0000:03:00.0 name mlxsw_erif
...
index 503
match_value:
type field_exact header mlxsw_meta field erif_port mapping ifindex
mapping_value 601 value 503
action_value:
type field_modify header mlxsw_meta field l3_forward value 1
The host4 table it is current size with no maximum.
The meaning of table size needs to be consistent across tables.
^ permalink raw reply
* Re: [patch net-next v2 00/10] Add support for resource abstraction
From: Jiri Pirko @ 2017-12-28 16:43 UTC (permalink / raw)
To: David Ahern
Cc: Yuval Mintz, netdev@vger.kernel.org, davem@davemloft.net,
Arkadi Sharshevsky, mlxsw, andrew@lunn.ch,
vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,
michael.chan@broadcom.com, ganeshgr@chelsio.com, Saeed Mahameed,
Matan Barak, Leon Romanovsky, Ido Schimmel,
jakub.kicinski@netronome.com, ast@kernel.org,
daniel@iogearbox.net, "
In-Reply-To: <4bd0a9d4-350d-274c-6370-e3a98a1e4f93@cumulusnetworks.com>
Thu, Dec 28, 2017 at 05:33:58PM CET, dsa@cumulusnetworks.com wrote:
>On 12/28/17 10:23 AM, Jiri Pirko wrote:
>>> So there are 4 tables exported to userspace:
>>>
>>> 1. mlxsw_erif table which is not in any of the kvd regions (no resource
>>> path is given) and it has a size of 1000. Does mlxsw_erif mean a rif as
>>> in Router Interfaces? So the switch supports up to 1000 router interfaces.
>>>
>>> 2. mlxsw_host4 in /kvd/hash_single with a size of 62. Based on the
>> Size tells you the actual size. It cannot give you max size. The reason
>> is simple. The resources are shared among multiple tables. That is
>> exactly what this resource patch makes visible.
>>
>>
>
>In the erif table, the 1000 is the max not current usage. I do not have
I believe that is a bug in erif dpipe implementation
(mlxsw_sp_dpipe_table_erif_size_get) We'll fix that. Thanks!
>1000 interfaces:
>
>$ ip -br li sh | wc -l
>597
>
>
>$ devlink dpipe table dump pci/0000:03:00.0 name mlxsw_erif
>...
> index 503
> match_value:
> type field_exact header mlxsw_meta field erif_port mapping ifindex
>mapping_value 601 value 503
> action_value:
> type field_modify header mlxsw_meta field l3_forward value 1
>
>
>The host4 table it is current size with no maximum.
>
>The meaning of table size needs to be consistent across tables.
^ permalink raw reply
* Re: [RFT net-next v2 0/3] dwmac-meson8b: RGMII clock fixes for Meson8b
From: Martin Blumenstingl @ 2017-12-28 16:58 UTC (permalink / raw)
To: Emiliano Ingrassia
Cc: netdev, linus.luessing, khilman, linux-amlogic, jbrunet,
Neil Armstrong, peppe.cavallaro, alexandre.torgue
In-Reply-To: <20171228161658.GA22727@ingrassia.epigenesys.com>
Hi Emiliano,
thank you for testing this!
On Thu, Dec 28, 2017 at 5:16 PM, Emiliano Ingrassia
<ingrassia@epigenesys.com> wrote:
> Hi Martin, Hi Dave,
>
> On Sun, Dec 24, 2017 at 12:40:57AM +0100, Martin Blumenstingl wrote:
>> Hi Dave,
>>
>> please do not apply this series until it got a Tested-by from Emiliano.
>>
>>
>> Hi Emiliano,
>>
>> you reported [0] that you couldn't get dwmac-meson8b to work on your
>> Odroid-C1. With your findings (register dumps, clk_summary output, etc.)
>> I think I was able to find a fix: it consists of two patches (which you
>> find in this series)
>>
>> Unfortunately I don't have any Meson8b boards with RGMII PHY so I could
>> only partially test this (I could only check if the clocks were
>> calculated correctly when using a dummy 500002394Hz input clock instead
>> of MPLL2).
>>
>> Could you please give this series a try and let me know about the
>> results?
>> You obviously still need your two "ARM: dts: meson8b" patches which
>> - add the amlogic,meson8b-dwmac" compatible to meson8b.dtsi
>> - enable Ethernet on the Odroid-C1
>>
>> I have tested this myself on a Khadas VIM (GXL SoC, internal RMII PHY)
>> and a Khadas VIM2 (GXM SoC, external RGMII PHY). Both are still working
>> fine (so let's hope that this also fixes your Meson8b issue :)).
>>
>>
>> changes since v1 at [1]:
>> - changed the subject of the cover-letter to indicate that this is all
>> about the RGMII clock
>> - added PATCH #1 which ensures that we don't unnecessarily change the
>> parent clocks in RMII mode (and also makes the code easier to
>> understand)
>> - changed subject of PATCH #2 (formerly PATCH #1) to state that this
>> is about the RGMII clock
>> - added Jerome's Reviewed-by to PATCH #2 (formerly PATCH #1)
>> - replaced PATCH #3 (formerly PATCH #2) with one that sets
>> CLK_SET_RATE_PARENT on the mux and thus re-configures the MPLL2 clock
>> on Meson8b correctly
>>
>
> Really thank you for your help and effort. I tried your patch but
> unfortunately it didn't solve the problem.
this is probably my fault: I forgot to mention that it requires a fix
for the 32-bit SoCs in the clock driver ("clk: meson: mpll: use 64-bit
maths in params_from_rate", see [0]) to work properly
>
> Here is the new clk_summary:
>
> xtal 1 1 24000000 0 0
> sys_pll 0 0 1200000000 0 0
> cpu_clk 0 0 1200000000 0 0
> vid_pll 0 0 732000000 0 0
> fixed_pll 2 2 2550000000 0 0
> mpll2 1 1 106250000 0 0
> c9410000.ethernet#m250_sel 1 1 106250000 0 0
> c9410000.ethernet#m250_div 1 1 106250000 0 0
> c9410000.ethernet#m25_div 1 1 21250000 0 0
>
> which leads to a value of 0x70a1 in the prg0 ethernet register.
> As you can see, something is changed but the RGMII clock is not at 25 MHz.
> In particular, the bit 10 of prg0, which enables the "generation of 25 MHz
> clock for PHY" (see S805 manual), is 0.
assuming that the description in the datasheet is correct
after Kevin and Mike got updated information from Amlogic about the
PRG_ETHERNET0 register documenation (see [1]) we thought that bit 10
means "0 = divide by 5, 1 = divide by 10" (see [2]). I didn't question
this so far, but I'll test this on a newer SoC later (by forcing
m250_div to 125MHz, then m25_div will have register value 0 = divide
by 5)
if the description from the documentation is correct then we need to
replace m25_div with a fixed-factor clock (mult = 1, div = 5) and make
it a m25_en gate clock instead
the resulting clock path would look like this: mpll2 > m250_sel >
m250_div > fixed_factor > m25_en
> Please, if you have other suggestions let me know.
could you please re-test this with the patch from [0] applied? no
other changes should be needed!
> Best regards,
>
> Emiliano
>
>>
>> [0] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005596.html
>> [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005848.html
>>
>>
>> Martin Blumenstingl (3):
>> net: stmmac: dwmac-meson8b: only configure the clocks in RGMII mode
>> net: stmmac: dwmac-meson8b: fix setting the RGMII clock on Meson8b
>> net: stmmac: dwmac-meson8b: propagate rate changes to the parent clock
>>
>> .../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 55 +++++++++++-----------
>> 1 file changed, 27 insertions(+), 28 deletions(-)
>>
>> --
>> 2.15.1
>>
Regards
Martin
[0] https://patchwork.kernel.org/patch/10131677/
[1] https://www.mail-archive.com/netdev@vger.kernel.org/msg119290.html
[2] https://www.mail-archive.com/netdev@vger.kernel.org/msg119293.html
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: display VNI correctly
From: David Miller @ 2017-12-28 17:00 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, santosh
In-Reply-To: <1514440792-30713-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Thu, 28 Dec 2017 11:29:52 +0530
> Fix incorrect VNI display in mps_tcam
>
> Signed-off-by: Santosh Rastapur <santosh@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v6 0/6] net: tcp: sctp: dccp: Replace jprobe usage with trace events
From: David Miller @ 2017-12-28 17:06 UTC (permalink / raw)
To: mhiramat
Cc: mingo, ian.mcdonald, vyasevich, stephen, rostedt, peterz, tglx,
linux-kernel, hpa, gerrit, nhorman, dccp, netdev, linux-sctp, sfr
In-Reply-To: <151444140014.11331.17287122201510506083.stgit@devbox>
From: Masami Hiramatsu <mhiramat@kernel.org>
Date: Thu, 28 Dec 2017 15:10:00 +0900
> Changes from v5:
> [1/6]: Avoid preprocessor directives in tracepoint macro args
Patch #1 is not the only patch which has this problem, at a minimum
patch #5 has it too.
Please audit the entire series for an issue when it is brought to your
attention.
Thank you.
^ permalink raw reply
* Fw: [Bug 198297] New: Unable to add ethX to bridge if ethX.<VLAN_ID> is already present in this bridge
From: Stephen Hemminger @ 2017-12-28 17:08 UTC (permalink / raw)
To: netdev
I don't think this is ever going to work as expected.
Begin forwarded message:
Date: Thu, 28 Dec 2017 08:38:37 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 198297] New: Unable to add ethX to bridge if ethX.<VLAN_ID> is already present in this bridge
https://bugzilla.kernel.org/show_bug.cgi?id=198297
Bug ID: 198297
Summary: Unable to add ethX to bridge if ethX.<VLAN_ID> is
already present in this bridge
Product: Networking
Version: 2.5
Kernel Version: 4.14.2
Hardware: ARM
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: alexander_cheremshinsky@yahoo.com
Regression: No
Kernel fails adding ethX to bridge if ethX.<VLAN_ID> is already present in this
bridge.
Steps to reproduce:
# vconfig add eth2 10
# brctl addbr br
# brctl addif br eth2.10
# brctl show
bridge name bridge id STP enabled interfaces
br 8000.0024a407481a no eth2.10
# brctl addif br eth2
can't add eth2 to bridge br: File exists
# brctl show
bridge name bridge id STP enabled interfaces
br 8000.0024a407481a no eth2.10
But it is ok if ethX is added before ethX.<VLAN_ID>
Steps to reproduce:
# brctl delif br eth2.10
# brctl addif br eth2
# brctl addif br eth2.10
# brctl show
bridge name bridge id STP enabled interfaces
br 8000.0024a407481a no eth2
eth2.10
So the result is depending on order of interface addition, that does not looks
logical as for me. This works good at least in kernel 3.10.70.
From my investigation it fails in function __netdev_upper_dev_link
(net/core/dev.c) on lines:
if (netdev_has_upper_dev(dev, upper_dev))
return -EEXIST;
I checked source code of kernel 4.14.8 but it looks the same and I think it
also has this issue.
I'm not so good with linux kernel to fix this by myself so it would be very
nice to get a patch with fix for this issue or explanation why such behavior is
correct.
Thanks in advance,
Alex.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4/cxgb4vf: support for XLAUI Port Type
From: David Miller @ 2017-12-28 17:09 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, leedom
In-Reply-To: <1514443035-15716-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Thu, 28 Dec 2017 12:07:15 +0530
> Add support for new Backplane XLAUI port type.
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v9 0/2] add UniPhier AVE ethernet support
From: David Miller @ 2017-12-28 17:11 UTC (permalink / raw)
To: hayashi.kunihiko
Cc: netdev, andrew, f.fainelli, robh+dt, mark.rutland,
linux-arm-kernel, linux-kernel, devicetree, yamada.masahiro,
masami.hiramatsu, jaswinder.singh
In-Reply-To: <1514444292-20643-1-git-send-email-hayashi.kunihiko@socionext.com>
From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date: Thu, 28 Dec 2017 15:58:10 +0900
> This series adds support for Socionext AVE ethernet controller implemented
> on UniPhier SoCs. This driver supports RGMII/RMII modes.
Series applied.
^ 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