* Re: [net PATCH V3] mlx4: fix XDP_TX is acting like XDP_PASS on TX ring full
From: Jesper Dangaard Brouer @ 2016-09-19 7:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev, tariqt, tom, bblanco, rana.shahot, brouer
In-Reply-To: <20160919.013925.1660395475687226712.davem@davemloft.net>
On Mon, 19 Sep 2016 01:39:25 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: Jesper Dangaard Brouer <brouer@redhat.com>
> Date: Sat, 17 Sep 2016 17:48:00 +0200
>
> > The XDP_TX action can fail transmitting the frame in case the TX ring
> > is full or port is down. In case of TX failure it should drop the
> > frame, and not as now call 'break' which is the same as XDP_PASS.
> >
> > Fixes: 9ecc2d86171a ("net/mlx4_en: add xdp forwarding and data write support")
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
>
> Oops, I applied v2 of this patch. Please send me any necessary
> relative fixups, thanks.
Okay, I just send the needed fix up in/with:
Subj: [net-next PATCH] mlx4: add missed recycle opportunity for XDP_TX on TX failure
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [net-next PATCH] mlx4: add missed recycle opportunity for XDP_TX on TX failure
From: Jesper Dangaard Brouer @ 2016-09-19 7:40 UTC (permalink / raw)
To: netdev, tariqt
Cc: tom, bblanco, rana.shahot, David S. Miller,
Jesper Dangaard Brouer
In-Reply-To: <20160919.013925.1660395475687226712.davem@davemloft.net>
Correct drop handling for XDP_TX on TX failure, were recently added in
commit 95357907ae73 ("mlx4: fix XDP_TX is acting like XDP_PASS on TX
ring full").
The change missed an opportunity for recycling the RX page, instead of
going through the page allocator, like the regular XDP_DROP action does.
This patch cease the opportunity, by going through the XDP_DROP case.
Fixes: 95357907ae73 ("mlx4: fix XDP_TX is acting like XDP_PASS on TX ring full")
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index c80073e4947f..919f0604d04a 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -906,11 +906,12 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
length, tx_index,
&doorbell_pending))
goto consumed;
- goto next; /* Drop on xmit failure */
+ goto xdp_drop; /* Drop on xmit failure */
default:
bpf_warn_invalid_xdp_action(act);
case XDP_ABORTED:
case XDP_DROP:
+ xdp_drop:
if (mlx4_en_rx_recycle(ring, frags))
goto consumed;
goto next;
^ permalink raw reply related
* Re: eBPF: how to check the flow table
From: Eric Leblond @ 2016-09-19 6:56 UTC (permalink / raw)
To: netdev; +Cc: Alexei Starovoitov, daniel
In-Reply-To: <1474200135.19872.12.camel@regit.org>
Hello,
On Sun, 2016-09-18 at 14:02 +0200, Eric Leblond wrote:
> Hello,
>
> I'm currently testing a code implementing AF_PACKET bypass for
> Suricata. The idea is that Suricata is updating a hash table
> containing
> a list of flows it does not want to see anymore.
>
> I want to check flow timeout from the userspace, so my current
> algorithm is doing:
>
> while (bpf_get_next_key(mapfd, &key, &next_key) == 0) {
> bpf_lookup_elem(mapfd, &next_key, &value);
> FlowCallback(mapfd, &next_key, &value, data);
> key = next_key;
> }
>
> In the FlowCallback, I check the timing in the flow entry and I
> remove
> the key if the flow is timeout.
>
> This is currently working well when there is only a few flows but on
> a
> real system with log of insertion in the table, the loop is never
> returning because we dequeue slower than we enqueue.
>
> Is there a better algorithm or an other way to do it ?
It seems I missed an obvious race condition in my existing code. I'll
continue to test and relive this thread if necessary.
BR,
--
Eric Leblond <eric@regit.org>
^ permalink raw reply
* [patch net-next] mlxsw: spectrum: Fix sparse warnings
From: Jiri Pirko @ 2016-09-19 6:29 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, eladr, yotamg, nogahf, ogerlitz
From: Ido Schimmel <idosch@mellanox.com>
drivers/net/ethernet/mellanox/mlxsw//spectrum.c:251:28: warning: symbol
'mlxsw_sp_span_entry_find' was not declared. Should it be static?
drivers/net/ethernet/mellanox/mlxsw//spectrum.c:265:28: warning: symbol
'mlxsw_sp_span_entry_get' was not declared. Should it be static?
drivers/net/ethernet/mellanox/mlxsw//spectrum.c:367:56: warning: mixing
different enum types
drivers/net/ethernet/mellanox/mlxsw//spectrum.c:367:56: int enum
mlxsw_sp_span_type versus
drivers/net/ethernet/mellanox/mlxsw//spectrum.c:367:56: int enum
mlxsw_reg_mpar_i_e
...
drivers/net/ethernet/mellanox/mlxsw//spectrum_buffers.c:598:32: warning:
mixing different enum types
drivers/net/ethernet/mellanox/mlxsw//spectrum_buffers.c:598:32: int
enum mlxsw_reg_sbxx_dir versus
drivers/net/ethernet/mellanox/mlxsw//spectrum_buffers.c:598:32: int
enum devlink_sb_pool_type
drivers/net/ethernet/mellanox/mlxsw//spectrum_buffers.c:600:39: warning:
mixing different enum types
drivers/net/ethernet/mellanox/mlxsw//spectrum_buffers.c:600:39: int
enum mlxsw_reg_sbpr_mode versus
drivers/net/ethernet/mellanox/mlxsw//spectrum_buffers.c:600:39: int
enum devlink_sb_threshold_type
...
drivers/net/ethernet/mellanox/mlxsw//spectrum_router.c:255:54: warning:
mixing different enum types
drivers/net/ethernet/mellanox/mlxsw//spectrum_router.c:255:54: int
enum mlxsw_sp_l3proto versus
drivers/net/ethernet/mellanox/mlxsw//spectrum_router.c:255:54: int
enum mlxsw_reg_ralxx_protocol
...
drivers/net/ethernet/mellanox/mlxsw//spectrum_router.c:1749:6: warning:
symbol 'mlxsw_sp_fib_entry_put' was not declared. Should it be static?
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 12 ++++---
.../net/ethernet/mellanox/mlxsw/spectrum_buffers.c | 15 ++++----
.../net/ethernet/mellanox/mlxsw/spectrum_router.c | 41 ++++++++++++++--------
3 files changed, 42 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 171f8dd..fa31261 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -248,7 +248,8 @@ static void mlxsw_sp_span_entry_destroy(struct mlxsw_sp *mlxsw_sp,
span_entry->used = false;
}
-struct mlxsw_sp_span_entry *mlxsw_sp_span_entry_find(struct mlxsw_sp_port *port)
+static struct mlxsw_sp_span_entry *
+mlxsw_sp_span_entry_find(struct mlxsw_sp_port *port)
{
struct mlxsw_sp *mlxsw_sp = port->mlxsw_sp;
int i;
@@ -262,7 +263,8 @@ struct mlxsw_sp_span_entry *mlxsw_sp_span_entry_find(struct mlxsw_sp_port *port)
return NULL;
}
-struct mlxsw_sp_span_entry *mlxsw_sp_span_entry_get(struct mlxsw_sp_port *port)
+static struct mlxsw_sp_span_entry
+*mlxsw_sp_span_entry_get(struct mlxsw_sp_port *port)
{
struct mlxsw_sp_span_entry *span_entry;
@@ -364,7 +366,8 @@ mlxsw_sp_span_inspected_port_bind(struct mlxsw_sp_port *port,
}
/* bind the port to the SPAN entry */
- mlxsw_reg_mpar_pack(mpar_pl, port->local_port, type, true, pa_id);
+ mlxsw_reg_mpar_pack(mpar_pl, port->local_port,
+ (enum mlxsw_reg_mpar_i_e) type, true, pa_id);
err = mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(mpar), mpar_pl);
if (err)
goto err_mpar_reg_write;
@@ -405,7 +408,8 @@ mlxsw_sp_span_inspected_port_unbind(struct mlxsw_sp_port *port,
return;
/* remove the inspected port */
- mlxsw_reg_mpar_pack(mpar_pl, port->local_port, type, false, pa_id);
+ mlxsw_reg_mpar_pack(mpar_pl, port->local_port,
+ (enum mlxsw_reg_mpar_i_e) type, false, pa_id);
mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(mpar), mpar_pl);
/* remove the SBIB buffer if it was egress SPAN */
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
index 953b214..bcaed8a 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
@@ -595,9 +595,9 @@ int mlxsw_sp_sb_pool_get(struct mlxsw_core *mlxsw_core,
enum mlxsw_reg_sbxx_dir dir = dir_get(pool_index);
struct mlxsw_sp_sb_pr *pr = mlxsw_sp_sb_pr_get(mlxsw_sp, pool, dir);
- pool_info->pool_type = dir;
+ pool_info->pool_type = (enum devlink_sb_pool_type) dir;
pool_info->size = MLXSW_SP_CELLS_TO_BYTES(pr->size);
- pool_info->threshold_type = pr->mode;
+ pool_info->threshold_type = (enum devlink_sb_threshold_type) pr->mode;
return 0;
}
@@ -608,9 +608,10 @@ int mlxsw_sp_sb_pool_set(struct mlxsw_core *mlxsw_core,
struct mlxsw_sp *mlxsw_sp = mlxsw_core_driver_priv(mlxsw_core);
u8 pool = pool_get(pool_index);
enum mlxsw_reg_sbxx_dir dir = dir_get(pool_index);
- enum mlxsw_reg_sbpr_mode mode = threshold_type;
u32 pool_size = MLXSW_SP_BYTES_TO_CELLS(size);
+ enum mlxsw_reg_sbpr_mode mode;
+ mode = (enum mlxsw_reg_sbpr_mode) threshold_type;
return mlxsw_sp_sb_pr_write(mlxsw_sp, pool, dir, mode, pool_size);
}
@@ -696,13 +697,13 @@ int mlxsw_sp_sb_tc_pool_bind_get(struct mlxsw_core_port *mlxsw_core_port,
struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp;
u8 local_port = mlxsw_sp_port->local_port;
u8 pg_buff = tc_index;
- enum mlxsw_reg_sbxx_dir dir = pool_type;
+ enum mlxsw_reg_sbxx_dir dir = (enum mlxsw_reg_sbxx_dir) pool_type;
struct mlxsw_sp_sb_cm *cm = mlxsw_sp_sb_cm_get(mlxsw_sp, local_port,
pg_buff, dir);
*p_threshold = mlxsw_sp_sb_threshold_out(mlxsw_sp, cm->pool, dir,
cm->max_buff);
- *p_pool_index = pool_index_get(cm->pool, pool_type);
+ *p_pool_index = pool_index_get(cm->pool, dir);
return 0;
}
@@ -716,7 +717,7 @@ int mlxsw_sp_sb_tc_pool_bind_set(struct mlxsw_core_port *mlxsw_core_port,
struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp;
u8 local_port = mlxsw_sp_port->local_port;
u8 pg_buff = tc_index;
- enum mlxsw_reg_sbxx_dir dir = pool_type;
+ enum mlxsw_reg_sbxx_dir dir = (enum mlxsw_reg_sbxx_dir) pool_type;
u8 pool = pool_get(pool_index);
u32 max_buff;
int err;
@@ -943,7 +944,7 @@ int mlxsw_sp_sb_occ_tc_port_bind_get(struct mlxsw_core_port *mlxsw_core_port,
struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp;
u8 local_port = mlxsw_sp_port->local_port;
u8 pg_buff = tc_index;
- enum mlxsw_reg_sbxx_dir dir = pool_type;
+ enum mlxsw_reg_sbxx_dir dir = (enum mlxsw_reg_sbxx_dir) pool_type;
struct mlxsw_sp_sb_cm *cm = mlxsw_sp_sb_cm_get(mlxsw_sp, local_port,
pg_buff, dir);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 3f5c51d..4afb498 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -252,7 +252,9 @@ static int mlxsw_sp_lpm_tree_alloc(struct mlxsw_sp *mlxsw_sp,
{
char ralta_pl[MLXSW_REG_RALTA_LEN];
- mlxsw_reg_ralta_pack(ralta_pl, true, lpm_tree->proto, lpm_tree->id);
+ mlxsw_reg_ralta_pack(ralta_pl, true,
+ (enum mlxsw_reg_ralxx_protocol) lpm_tree->proto,
+ lpm_tree->id);
return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(ralta), ralta_pl);
}
@@ -261,7 +263,9 @@ static int mlxsw_sp_lpm_tree_free(struct mlxsw_sp *mlxsw_sp,
{
char ralta_pl[MLXSW_REG_RALTA_LEN];
- mlxsw_reg_ralta_pack(ralta_pl, false, lpm_tree->proto, lpm_tree->id);
+ mlxsw_reg_ralta_pack(ralta_pl, false,
+ (enum mlxsw_reg_ralxx_protocol) lpm_tree->proto,
+ lpm_tree->id);
return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(ralta), ralta_pl);
}
@@ -384,7 +388,9 @@ static int mlxsw_sp_vr_lpm_tree_bind(struct mlxsw_sp *mlxsw_sp,
{
char raltb_pl[MLXSW_REG_RALTB_LEN];
- mlxsw_reg_raltb_pack(raltb_pl, vr->id, vr->proto, vr->lpm_tree->id);
+ mlxsw_reg_raltb_pack(raltb_pl, vr->id,
+ (enum mlxsw_reg_ralxx_protocol) vr->proto,
+ vr->lpm_tree->id);
return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(raltb), raltb_pl);
}
@@ -394,7 +400,8 @@ static int mlxsw_sp_vr_lpm_tree_unbind(struct mlxsw_sp *mlxsw_sp,
char raltb_pl[MLXSW_REG_RALTB_LEN];
/* Bind to tree 0 which is default */
- mlxsw_reg_raltb_pack(raltb_pl, vr->id, vr->proto, 0);
+ mlxsw_reg_raltb_pack(raltb_pl, vr->id,
+ (enum mlxsw_reg_ralxx_protocol) vr->proto, 0);
return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(raltb), raltb_pl);
}
@@ -1081,9 +1088,10 @@ static int mlxsw_sp_adj_index_mass_update_vr(struct mlxsw_sp *mlxsw_sp,
{
char raleu_pl[MLXSW_REG_RALEU_LEN];
- mlxsw_reg_raleu_pack(raleu_pl, vr->proto, vr->id,
- adj_index, ecmp_size,
- new_adj_index, new_ecmp_size);
+ mlxsw_reg_raleu_pack(raleu_pl,
+ (enum mlxsw_reg_ralxx_protocol) vr->proto, vr->id,
+ adj_index, ecmp_size, new_adj_index,
+ new_ecmp_size);
return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(raleu), raleu_pl);
}
@@ -1558,8 +1566,9 @@ static int mlxsw_sp_fib_entry_op4_remote(struct mlxsw_sp *mlxsw_sp,
trap_id = MLXSW_TRAP_ID_RTR_INGRESS0;
}
- mlxsw_reg_ralue_pack4(ralue_pl, vr->proto, op, vr->id,
- fib_entry->key.prefix_len, *p_dip);
+ mlxsw_reg_ralue_pack4(ralue_pl,
+ (enum mlxsw_reg_ralxx_protocol) vr->proto, op,
+ vr->id, fib_entry->key.prefix_len, *p_dip);
mlxsw_reg_ralue_act_remote_pack(ralue_pl, trap_action, trap_id,
adjacency_index, ecmp_size);
return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(ralue), ralue_pl);
@@ -1573,8 +1582,9 @@ static int mlxsw_sp_fib_entry_op4_local(struct mlxsw_sp *mlxsw_sp,
u32 *p_dip = (u32 *) fib_entry->key.addr;
struct mlxsw_sp_vr *vr = fib_entry->vr;
- mlxsw_reg_ralue_pack4(ralue_pl, vr->proto, op, vr->id,
- fib_entry->key.prefix_len, *p_dip);
+ mlxsw_reg_ralue_pack4(ralue_pl,
+ (enum mlxsw_reg_ralxx_protocol) vr->proto, op,
+ vr->id, fib_entry->key.prefix_len, *p_dip);
mlxsw_reg_ralue_act_local_pack(ralue_pl,
MLXSW_REG_RALUE_TRAP_ACTION_NOP, 0,
fib_entry->rif);
@@ -1589,8 +1599,9 @@ static int mlxsw_sp_fib_entry_op4_trap(struct mlxsw_sp *mlxsw_sp,
u32 *p_dip = (u32 *) fib_entry->key.addr;
struct mlxsw_sp_vr *vr = fib_entry->vr;
- mlxsw_reg_ralue_pack4(ralue_pl, vr->proto, op, vr->id,
- fib_entry->key.prefix_len, *p_dip);
+ mlxsw_reg_ralue_pack4(ralue_pl,
+ (enum mlxsw_reg_ralxx_protocol) vr->proto, op,
+ vr->id, fib_entry->key.prefix_len, *p_dip);
mlxsw_reg_ralue_act_ip2me_pack(ralue_pl);
return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(ralue), ralue_pl);
}
@@ -1753,8 +1764,8 @@ mlxsw_sp_fib_entry_find(struct mlxsw_sp *mlxsw_sp,
fib4->fi->fib_dev);
}
-void mlxsw_sp_fib_entry_put(struct mlxsw_sp *mlxsw_sp,
- struct mlxsw_sp_fib_entry *fib_entry)
+static void mlxsw_sp_fib_entry_put(struct mlxsw_sp *mlxsw_sp,
+ struct mlxsw_sp_fib_entry *fib_entry)
{
struct mlxsw_sp_vr *vr = fib_entry->vr;
--
2.5.5
^ permalink raw reply related
* [patch net-next] mlxsw: Change the RX LAG hash function from XOR to CRC
From: Jiri Pirko @ 2016-09-19 6:28 UTC (permalink / raw)
To: netdev; +Cc: davem, eladr, idosch, yotamg, nogahf, ogerlitz
From: Elad Raz <eladr@mellanox.com>
Change the RX hash function from XOR to CRC in order to have better
distribution of the traffic.
Signed-off-by: Elad Raz <eladr@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/reg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/reg.h b/drivers/net/ethernet/mellanox/mlxsw/reg.h
index 4e2354c..6460c72 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/reg.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/reg.h
@@ -1392,7 +1392,7 @@ static inline void mlxsw_reg_slcr_pack(char *payload, u16 lag_hash)
{
MLXSW_REG_ZERO(slcr, payload);
mlxsw_reg_slcr_pp_set(payload, MLXSW_REG_SLCR_PP_GLOBAL);
- mlxsw_reg_slcr_type_set(payload, MLXSW_REG_SLCR_TYPE_XOR);
+ mlxsw_reg_slcr_type_set(payload, MLXSW_REG_SLCR_TYPE_CRC);
mlxsw_reg_slcr_lag_hash_set(payload, lag_hash);
}
--
2.5.5
^ permalink raw reply related
* Re: [PATCH] net: skbuff: Fix length validation in skb_vlan_pop()
From: Shmulik Ladkani @ 2016-09-19 6:15 UTC (permalink / raw)
To: pravin shelar
Cc: Jiri Pirko, David S . Miller, Linux Kernel Network Developers
In-Reply-To: <CAOrHB_D2ytTK9WjfCPL87E1QomeXg+2GfAvo8N8xCcJULhAC=w@mail.gmail.com>
Hi,
On Sun, 18 Sep 2016 13:26:30 -0700, pshelar@ovn.org wrote:
> On Sun, Sep 18, 2016 at 3:09 AM, Shmulik Ladkani
> <shmulik.ladkani@gmail.com> wrote:
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index 1e329d4112..cc2c004838 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -4537,7 +4537,7 @@ int skb_vlan_pop(struct sk_buff *skb)
> > } else {
> > if (unlikely((skb->protocol != htons(ETH_P_8021Q) &&
> > skb->protocol != htons(ETH_P_8021AD)) ||
> > - skb->len < VLAN_ETH_HLEN))
> > + skb->mac_len < VLAN_ETH_HLEN))
>
> There is already check in __skb_vlan_pop() to validate skb for a vlan
> header. So it is safe to drop this check entirely.
Seems validation in '__skb_vlan_pop' has slightly different semantics:
unsigned int offset = skb->data - skb_mac_header(skb);
__skb_push(skb, offset);
err = skb_ensure_writable(skb, VLAN_ETH_HLEN);
this pushes 'data' back to mac_header, then makes sure there's sufficient
place in skb to _store_ VLAN_ETH_HLEN bytes (by pulling into linear part
if needed, or erroring if skb is too small).
There's no guarantee the original mac header was sized VLAN_ETH_HLEN.
Interpretation of the following
if (unlikely((skb->protocol != htons(ETH_P_8021Q) &&
skb->protocol != htons(ETH_P_8021AD)) ||
skb->len < VLAN_ETH_HLEN))
return 0;
in 'skb_vlan_pop' might be read as:
"there's no tag, or protocol says its a tag but it's insufficient to pop,
so lets do nothing".
Is it superflous?
Thanks,
Shmulik
^ permalink raw reply
* Re: [patch net-next RFC 0/2] fib4 offload: notifier to let hw to be aware of all prefixes
From: Jiri Pirko @ 2016-09-19 6:14 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Florian Fainelli, netdev, davem, idosch, eladr, yotamg, nogahf,
ogerlitz, nikolay, linville, tgraf, gospo, sfeldma, ast, edumazet,
hannes, dsa, jhs, vivien.didelot, john.fastabend, andrew, ivecera
In-Reply-To: <57DF2041.3040509@cumulusnetworks.com>
Mon, Sep 19, 2016 at 01:16:17AM CEST, roopa@cumulusnetworks.com wrote:
>On 9/18/16, 1:00 PM, Florian Fainelli wrote:
>> Le 06/09/2016 à 05:01, Jiri Pirko a écrit :
>>> From: Jiri Pirko <jiri@mellanox.com>
>>>
>>> This is RFC, unfinished. I came across some issues in the process so I would
>>> like to share those and restart the fib offload discussion in order to make it
>>> really usable.
>>>
>>> So the goal of this patchset is to allow driver to propagate all prefixes
>>> configured in kernel down HW. This is necessary for routing to work
>>> as expected. If we don't do that HW might forward prefixes known to kernel
>>> incorrectly. Take an example when default route is set in switch HW and there
>>> is an IP address set on a management (non-switch) port.
>>>
>>> Currently, only fibs related to the switch port netdev are offloaded using
>>> switchdev ops. This model is not extendable so the first patch introduces
>>> a replacement: notifier to propagate fib additions and removals to whoever
>>> interested. The second patch makes mlxsw to adopt this new way, registering
>>> one notifier block for each mlxsw (asic) instance.
>> Instead of introducing another specialization of a notifier_block
>> implementation, could we somehow have a kernel-based netlink listener
>> which receives the same kind of event information from rtmsg_fib()?
>>
>> The reason is that having such a facility would hook directly onto
>> existing rtmsg_* calls that exist throughout the stack, and that seems
>> to scale better.
>I was thinking along the same lines. Instead of proliferating notifier blocks
>through-out the stack for switchdev offload, putting existing events to use would be nice.
>
>But the problem though is drivers having to parse the netlink msg again. also, the intent
>here is to do the offload first ..before the route is added to the kernel (though i don't see that in
>the current series). existing netlink rmsg_fib events are generated after the route is added to the kernel.
>
>
>Jiri, instead of the notifier, do you see a problem with always calling the existing switchdev
>offload api for every route for every asic instance ?. the first device where the route fits wins.
There is not list of asic instances. Therefore the notifier fits much better here.
>it seems similar to driver registering for notifier and looking at every route ...
>am i missing something ?
>and the policies you mention could help around selecting the asic instance (FCFS or mirror).
>you will need to abstract out the asic instance for switchdev api to call on, but I thought you
>already have that in some form in your devlink infrastructure.
switchdev asic instances and devlink instances are orthogonal.
^ permalink raw reply
* Re: [patch net-next RFC 0/2] fib4 offload: notifier to let hw to be aware of all prefixes
From: Jiri Pirko @ 2016-09-19 6:08 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, davem, idosch, eladr, yotamg, nogahf, ogerlitz, roopa,
nikolay, linville, tgraf, gospo, sfeldma, ast, edumazet, hannes,
dsa, jhs, vivien.didelot, john.fastabend, andrew, ivecera
In-Reply-To: <fc177125-a9b8-fcce-281b-5fdc25639944@gmail.com>
Sun, Sep 18, 2016 at 10:00:44PM CEST, f.fainelli@gmail.com wrote:
>Le 06/09/2016 à 05:01, Jiri Pirko a écrit :
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> This is RFC, unfinished. I came across some issues in the process so I would
>> like to share those and restart the fib offload discussion in order to make it
>> really usable.
>>
>> So the goal of this patchset is to allow driver to propagate all prefixes
>> configured in kernel down HW. This is necessary for routing to work
>> as expected. If we don't do that HW might forward prefixes known to kernel
>> incorrectly. Take an example when default route is set in switch HW and there
>> is an IP address set on a management (non-switch) port.
>>
>> Currently, only fibs related to the switch port netdev are offloaded using
>> switchdev ops. This model is not extendable so the first patch introduces
>> a replacement: notifier to propagate fib additions and removals to whoever
>> interested. The second patch makes mlxsw to adopt this new way, registering
>> one notifier block for each mlxsw (asic) instance.
>
>Instead of introducing another specialization of a notifier_block
>implementation, could we somehow have a kernel-based netlink listener
>which receives the same kind of event information from rtmsg_fib()?
rtmsg_fib destination is userspace. The message format is netlink. I
don't think it is wise to pass netlink messages inside kernel when we
can pass nice structures. Lower overhead. This is how it is done in the
rest of kernel. Not sure how your comment is related specifically to
this patch.
>
>The reason is that having such a facility would hook directly onto
>existing rtmsg_* calls that exist throughout the stack, and that seems
>to scale better.
>--
>Florian
^ permalink raw reply
* Re: [patch net-next RFC 1/2] fib: introduce fib notification infrastructure
From: Jiri Pirko @ 2016-09-19 6:06 UTC (permalink / raw)
To: Roopa Prabhu
Cc: netdev, davem, idosch, eladr, yotamg, nogahf, ogerlitz, nikolay,
linville, tgraf, gospo, sfeldma, ast, edumazet, hannes,
f.fainelli, dsa, jhs, vivien.didelot, john.fastabend, andrew,
ivecera
In-Reply-To: <57DF2203.4000903@cumulusnetworks.com>
Mon, Sep 19, 2016 at 01:23:47AM CEST, roopa@cumulusnetworks.com wrote:
>On 9/6/16, 5:01 AM, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> This allows to pass information about added/deleted fib entries to
>> whoever is interested. This is done in a very similar way as devinet
>> notifies address additions/removals.
>>
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>> ---
>> include/net/ip_fib.h | 19 +++++++++++++++++++
>> net/ipv4/fib_trie.c | 43 +++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 62 insertions(+)
>>
>> diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
>> index 4079fc1..9ad7ba9 100644
>> --- a/include/net/ip_fib.h
>> +++ b/include/net/ip_fib.h
>> @@ -22,6 +22,7 @@
>> #include <net/fib_rules.h>
>> #include <net/inetpeer.h>
>> #include <linux/percpu.h>
>> +#include <linux/notifier.h>
>>
>> struct fib_config {
>> u8 fc_dst_len;
>> @@ -184,6 +185,24 @@ __be32 fib_info_update_nh_saddr(struct net *net, struct fib_nh *nh);
>> #define FIB_RES_PREFSRC(net, res) ((res).fi->fib_prefsrc ? : \
>> FIB_RES_SADDR(net, res))
>>
>> +struct fib_notifier_info {
>> + u32 dst;
>> + int dst_len;
>> + struct fib_info *fi;
>> + u8 tos;
>> + u8 type;
>> + u32 tb_id;
>> + u32 nlflags;
>> +};
>> +
>> +enum fib_event_type {
>> + FIB_EVENT_TYPE_ADD,
>> + FIB_EVENT_TYPE_DEL,
>> +};
>> +
>> +int register_fib_notifier(struct notifier_block *nb);
>> +int unregister_fib_notifier(struct notifier_block *nb);
>> +
>> struct fib_table {
>> struct hlist_node tb_hlist;
>> u32 tb_id;
>> diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
>> index e2ffc2a..19ec471 100644
>> --- a/net/ipv4/fib_trie.c
>> +++ b/net/ipv4/fib_trie.c
>> @@ -73,6 +73,7 @@
>> #include <linux/slab.h>
>> #include <linux/export.h>
>> #include <linux/vmalloc.h>
>> +#include <linux/notifier.h>
>> #include <net/net_namespace.h>
>> #include <net/ip.h>
>> #include <net/protocol.h>
>> @@ -84,6 +85,36 @@
>> #include <trace/events/fib.h>
>> #include "fib_lookup.h"
>>
>> +static BLOCKING_NOTIFIER_HEAD(fib_chain);
>> +
>> +int register_fib_notifier(struct notifier_block *nb)
>> +{
>> + return blocking_notifier_chain_register(&fib_chain, nb);
>> +}
>> +EXPORT_SYMBOL(register_fib_notifier);
>> +
>> +int unregister_fib_notifier(struct notifier_block *nb)
>> +{
>> + return blocking_notifier_chain_unregister(&fib_chain, nb);
>> +}
>> +EXPORT_SYMBOL(unregister_fib_notifier);
>> +
>> +static int call_fib_notifiers(enum fib_event_type event_type, u32 dst,
>> + int dst_len, struct fib_info *fi,
>> + u8 tos, u8 type, u32 tb_id, u32 nlflags)
>> +{
>> + struct fib_notifier_info info = {
>> + .dst = dst,
>> + .dst_len = dst_len,
>> + .fi = fi,
>> + .tos = tos,
>> + .type = type,
>> + .tb_id = tb_id,
>> + .nlflags = nlflags,
>> + };
>> + return blocking_notifier_call_chain(&fib_chain, event_type, &info);
>> +}
>> +
>> #define MAX_STAT_DEPTH 32
>>
>> #define KEYLENGTH (8*sizeof(t_key))
>> @@ -1190,6 +1221,10 @@ int fib_table_insert(struct fib_table *tb, struct fib_config *cfg)
>> fib_release_info(fi_drop);
>> if (state & FA_S_ACCESSED)
>> rt_cache_flush(cfg->fc_nlinfo.nl_net);
>> +
>> + call_fib_notifiers(FIB_EVENT_TYPE_ADD, key, plen, fi,
>> + new_fa->fa_tos, cfg->fc_type,
>> + tb->tb_id, cfg->fc_nlflags);
>> rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen,
>> tb->tb_id, &cfg->fc_nlinfo, NLM_F_REPLACE);
>>
>> @@ -1241,6 +1276,8 @@ int fib_table_insert(struct fib_table *tb, struct fib_config *cfg)
>> tb->tb_num_default++;
>>
>> rt_cache_flush(cfg->fc_nlinfo.nl_net);
>> + call_fib_notifiers(FIB_EVENT_TYPE_ADD, key, plen, fi, tos,
>> + cfg->fc_type, tb->tb_id, cfg->fc_nlflags);
>
>
>It appears that this is in addition to the existing switchdev_fib_ipv4_add call right above this.
>Is the intent to do both ?. i don't see a need to do both.
I already have patchset improved that it removes the switchdev fib code.
Have to do some more testing, will send it soon.
>
>and switchdev_fib_ipv4_add offloads before the route is added to the kernel.
>But the notifier seems to fire after the route is added to the kernel.
Yeah, I wanted to align it with rtmsg_fib calls. Also I think it makes
sense to have slowpath ready before offload.
>
>> rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen, new_fa->tb_id,
>> &cfg->fc_nlinfo, nlflags);
>> succeeded:
>> @@ -1542,6 +1579,8 @@ int fib_table_delete(struct fib_table *tb, struct fib_config *cfg)
>> switchdev_fib_ipv4_del(key, plen, fa_to_delete->fa_info, tos,
>> cfg->fc_type, tb->tb_id);
>>
>> + call_fib_notifiers(FIB_EVENT_TYPE_DEL, key, plen, fa_to_delete->fa_info,
>> + tos, cfg->fc_type, tb->tb_id, 0);
>> rtmsg_fib(RTM_DELROUTE, htonl(key), fa_to_delete, plen, tb->tb_id,
>> &cfg->fc_nlinfo, 0);
>>
>> @@ -1857,6 +1896,10 @@ int fib_table_flush(struct fib_table *tb)
>> switchdev_fib_ipv4_del(n->key, KEYLENGTH - fa->fa_slen,
>> fi, fa->fa_tos, fa->fa_type,
>> tb->tb_id);
>> + call_fib_notifiers(FIB_EVENT_TYPE_DEL, n->key,
>> + KEYLENGTH - fa->fa_slen,
>> + fi, fa->fa_tos, fa->fa_type,
>> + tb->tb_id, 0);
>> hlist_del_rcu(&fa->fa_list);
>> fib_release_info(fa->fa_info);
>> alias_free_mem_rcu(fa);
>
^ permalink raw reply
* Re: [PATCH net-next 00/11] rxrpc: Tracepoint addition and improvement
From: David Miller @ 2016-09-19 5:53 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <147415448967.18436.14900942726390485534.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Sun, 18 Sep 2016 00:21:29 +0100
> Tagged thusly:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> rxrpc-rewrite-20160917-2
Pulled.
^ permalink raw reply
* Re: [PATCH net-next 00/14] rxrpc: Fixes & miscellany
From: David Miller @ 2016-09-19 5:53 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <147415426459.17897.13899206413543061473.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Sun, 18 Sep 2016 00:17:44 +0100
> Tagged thusly:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> rxrpc-rewrite-20160917-1
Pulled.
^ permalink raw reply
* Re: [PATCH net-next 0/5] sched: convert queues to single-linked list
From: David Miller @ 2016-09-19 5:47 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <1474153054-9059-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Sun, 18 Sep 2016 00:57:29 +0200
> During Netfilter Workshop 2016 Eric Dumazet pointed out that qdisc
> schedulers use doubly-linked lists, even though single-linked list
> would be enough.
>
> The double-linked skb lists incur one extra write on enqueue/dequeue
> operations (to change ->prev pointer of next list elem).
>
> This series converts qdiscs to single-linked version, listhead
> maintains pointers to first (for dequeue) and last skb (for enqueue).
>
> Most qdiscs don't queue at all and instead use a leaf qdisc (typically
> pfifo_fast) so only a few schedulers needed changes.
>
> I briefly tested netem and htb and they seemed fine.
>
> UDP_STREAM netperf with 64 byte packets via veth+pfifo_fast shows
> a small (~2%) improvement.
Series applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH -next] cxgb4: Fix return value check in cfg_queues_uld()
From: David Miller @ 2016-09-19 5:42 UTC (permalink / raw)
To: weiyj.lk; +Cc: hariprasad, weiyongjun1, netdev
In-Reply-To: <1474127537-14230-1-git-send-email-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Sat, 17 Sep 2016 15:52:17 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix the retrn value check which testing the wrong variable
> in cfg_queues_uld().
>
> Fixes: 94cdb8bb993a ("cxgb4: Add support for dynamic allocation of
> resources for ULD")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v3 0/3] net: ethernet: mediatek: add HW LRO functions
From: David Miller @ 2016-09-19 5:41 UTC (permalink / raw)
To: nelson.chang; +Cc: john, nbd, netdev, linux-mediatek, nelsonch.tw
In-Reply-To: <1474127650-20271-1-git-send-email-nelson.chang@mediatek.com>
From: Nelson Chang <nelson.chang@mediatek.com>
Date: Sat, 17 Sep 2016 23:54:07 +0800
> The series add the large receive offload (LRO) functions by hardware and
> the ethtool functions to configure RX flows of HW LRO.
Series applied.
^ permalink raw reply
* Re: [net PATCH V3] mlx4: fix XDP_TX is acting like XDP_PASS on TX ring full
From: David Miller @ 2016-09-19 5:39 UTC (permalink / raw)
To: brouer; +Cc: netdev, tariqt, tom, bblanco, rana.shahot
In-Reply-To: <20160917154753.3130.16986.stgit@firesoul>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Sat, 17 Sep 2016 17:48:00 +0200
> The XDP_TX action can fail transmitting the frame in case the TX ring
> is full or port is down. In case of TX failure it should drop the
> frame, and not as now call 'break' which is the same as XDP_PASS.
>
> Fixes: 9ecc2d86171a ("net/mlx4_en: add xdp forwarding and data write support")
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Oops, I applied v2 of this patch. Please send me any necessary
relative fixups, thanks.
^ permalink raw reply
* Re: stmmac/RTL8211F/Meson GXBB: TX throughput problems
From: Giuseppe CAVALLARO @ 2016-09-19 5:38 UTC (permalink / raw)
To: André Roth
Cc: Martin Blumenstingl, netdev, linux-amlogic, Alexandre Torgue
In-Reply-To: <20160918224240.0bf5a9ed@gmail.com>
Hello André
On 9/18/2016 10:42 PM, André Roth wrote:
>
> Hello,
>
>> For example, you could try disabling the scatter-gather or tx-cum
>> via ethtool and seeing if there is some benefit; so we could image
>> some problem on your HW or SYNP MAC integration for checksumming
>> on tx side.
>
> disabling the following:
> ethtool -K eth0 sg off
> or:
> ethtool -K eth0 tx off
> does not prevent the network communication going down..
>
>> Also you could check the AXI tuning and PBL value. To be honest
>> (thinking about your problem) I can actually suspect some related
>> problem on bus setup. So I suggest you to play with these value
>> (better if you ask for having values from HW validation on your side).
>> Otherwise the stmmac uses a default that cannot be good for your
>> platform. For example, sometime I have seen that PBL is better if
>> reduced to 8 instead of 32 and w/o 4xPBL...
>
> how can I set those values ?
>
> thanks for your time,
welcome
take a look at Documentation/devicetree/bindings/net/stmmac.txt
peppe
>
> andre
>
>
^ permalink raw reply
* Re: [PATCH net-next] chcr/cxgb4i/cxgbit/RDMA/cxgb4: Allocate resources dynamically for all cxgb4 ULD's
From: David Miller @ 2016-09-19 5:38 UTC (permalink / raw)
To: hariprasad
Cc: netdev, linux-scsi, target-devel, linux-rdma, linux-crypto, nab,
jejb, martin.petersen, dledford, herbert, varun, nirranjan, swise,
atul.gupta, rahul.lakkireddy
In-Reply-To: <1474080159-14980-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Sat, 17 Sep 2016 08:12:39 +0530
> Allocate resources dynamically to cxgb4's Upper layer driver's(ULD) like
> cxgbit, iw_cxgb4 and cxgb4i. Allocate resources when they register with
> cxgb4 driver and free them while unregistering. All the queues and the
> interrupts for them will be allocated during ULD probe only and freed
> during remove.
>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH resend] sctp: Remove some redundant code
From: David Miller @ 2016-09-19 5:34 UTC (permalink / raw)
To: christophe.jaillet
Cc: marcelo.leitner, vyasevich, nhorman, linux-sctp, netdev,
linux-kernel, kernel-janitors
In-Reply-To: <1474059935-17343-1-git-send-email-christophe.jaillet@wanadoo.fr>
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Fri, 16 Sep 2016 23:05:35 +0200
> In commit 311b21774f13 ("sctp: simplify sk_receive_queue locking"), a call
> to 'skb_queue_splice_tail_init()' has been made explicit. Previously it was
> hidden in 'sctp_skb_list_tail()'
>
> Now, the code around it looks redundant. The '_init()' part of
> 'skb_queue_splice_tail_init()' should already do the same.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied to net-next.
^ permalink raw reply
* Re: [net PATCH] mlx4: fix XDP_TX is acting like XDP_PASS on TX ring full
From: David Miller @ 2016-09-19 5:32 UTC (permalink / raw)
To: brouer; +Cc: netdev, tariqt, eric.dumazet, tom, bblanco, rana.shahot
In-Reply-To: <20160916203535.20016.45146.stgit@firesoul>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Fri, 16 Sep 2016 22:36:12 +0200
> The XDP_TX action can fail transmitting the frame in case the TX ring
> is full or port is down. In case of TX failure it should drop the
> frame, and not as now call 'break' which is the same as XDP_PASS.
>
> Fixes: 9ecc2d86171a ("net/mlx4_en: add xdp forwarding and data write support")
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
This patch is for net-next, please be explicit about that in the future.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/5] mlx4 misc fixes and improvements
From: Or Gerlitz @ 2016-09-19 5:32 UTC (permalink / raw)
To: David Miller
Cc: Tariq Toukan, Tariq Toukan, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <20160918.220046.1374771296032853447.davem@davemloft.net>
On Mon, Sep 19, 2016 at 5:00 AM, David Miller <davem@davemloft.net> wrote:
> From: Tariq Toukan <ttoukan.linux@gmail.com>
> Date: Sun, 18 Sep 2016 10:27:23 +0300
>
>> Hi Dave,
>>
>> On 16/09/2016 2:21 AM, David Miller wrote:
>>> From: Tariq Toukan <tariqt@mellanox.com>
>>> Date: Mon, 12 Sep 2016 16:20:11 +0300
>>>
>>>> This patchset contains some bug fixes, a cleanup, and small
>>>> improvements
>>>> from the team to the mlx4 Eth and core drivers.
>>>>
>>>> Series generated against net-next commit:
>>>> 02154927c115 "net: dsa: bcm_sf2: Get VLAN_PORT_MASK from b53_device"
>>>>
>>>> Please push the following patch to -stable >= 4.6 as well:
>>>> "net/mlx4_core: Fix to clean devlink resources"
>>> Again, coding style fixes and optimizations like branch prediction
>>> hints are not bug fixes and therefore not appropriate for 'net'.
>> Yes, I know. Please notice that it was submitted to net-next this
>> time.
>
> This is completely incompatible with a request for one of the changes
> to go into -stable.
>
> If the change is not in 'net', it can't go to -stable.
Dave,
So when we're pretty late in the 4.8-rc cycle, a fix for a problem
which was not introduced in 4.8-rc1 was targeted to net-next (4.9) and
not net.
This indeed creates a small mess when the fix needs to go to -stable as well.
I guess the correct thing to do next time, would be to either send to
net and ask you to take it to stable as part of picking the patch --
or send to net-next, and later send you a request to put it to stable
-- or, wait a bit and send it to net of the next kernel along with
stable request... we will pick one of these three way of doings next
(...) time.
So, at this point, I think it would be just correct to take the series
to net-next, and on a future point we'll issue a request to push the
patch into stable.
Or.
Or.
^ permalink raw reply
* Re: [PATCH v4 net 1/1] net sched actions: fix GETing actions
From: David Miller @ 2016-09-19 5:30 UTC (permalink / raw)
To: jhs; +Cc: netdev, xiyou.wangcong
In-Reply-To: <1474057624-17914-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Fri, 16 Sep 2016 16:27:04 -0400
> Fixes:
> commit 22dc13c837c3 ("net_sched: convert tcf_exts from list to pointer array"),
> commit 824a7e8863b3 ("net_sched: remove an unnecessary list_del()")
> commit f07fed82ad79 ("net_sched: remove the leftover cleanup_a()")
Please use multiple "Fixes: " lines to reference multiple commits, like so:
Fixes: 22dc13c837c3 ("net_sched: convert tcf_exts from list to pointer array"),
Fixes: 824a7e8863b3 ("net_sched: remove an unnecessary list_del()")
Fixes: f07fed82ad79 ("net_sched: remove the leftover cleanup_a()")
> +static void cleanup_a(struct list_head *actions, int ovr)
> +{
> + struct tc_action *a;
> +
> + list_for_each_entry(a, actions, list) {
> + if (ovr)
> + a->tcfa_refcnt--;
> + }
> +}
Please move the invariant test outside of the loop, like so:
if (!ovr)
return;
list_for_each_entry(a, actions, list)
a->tcfa_refcnt--;
Thanks.
^ permalink raw reply
* Re: [PATCHv4 next 0/3] IPvlan introduce l3s mode
From: David Miller @ 2016-09-19 5:25 UTC (permalink / raw)
To: mahesh; +Cc: netdev, edumazet, maheshb
In-Reply-To: <1474055941-12353-1-git-send-email-mahesh@bandewar.net>
From: Mahesh Bandewar <mahesh@bandewar.net>
Date: Fri, 16 Sep 2016 12:59:01 -0700
> Same old problem with new approach especially from suggestions from
> earlier patch-series.
>
> First thing is that this is introduced as a new mode rather than
> modifying the old (L3) mode. So the behavior of the existing modes is
> preserved as it is and the new L3s mode obeys iptables so that intended
> conn-tracking can work.
>
> To do this, the code uses newly added l3mdev_rcv() handler and an
> Iptables hook. l3mdev_rcv() to perform an inbound route lookup with the
> correct (IPvlan slave) interface and then IPtable-hook at LOCAL_INPUT
> to change the input device from master to the slave to complete the
> formality.
>
> Supporting stack changes are trivial changes to export symbol to get
> IPv4 equivalent code exported for IPv6 and to allow netfilter hook
> registration code to allow caller to hold RTNL. Please look into
> individual patches for details.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/2] cxgb4 FR_NSMR_TPTE_WR support
From: David Miller @ 2016-09-19 5:16 UTC (permalink / raw)
To: swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1474037695.git.swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
From: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
Date: Fri, 16 Sep 2016 07:54:55 -0700
> This series enables a new work request to optimize small REG_MR
> operations. This is intended for 4.9. If everyone agrees, I suggest
> Doug take both the cxgb4 and iw_cxgb4 patches through his tree.
I'm assuming this mean that I do _not_ apply these to my tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: ipv6: fallback to full lookup if table lookup is unsuitable
From: David Miller @ 2016-09-19 4:58 UTC (permalink / raw)
To: vincent; +Cc: dsa, kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <20160916125531.3486-1-vincent@bernat.im>
From: Vincent Bernat <vincent@bernat.im>
Date: Fri, 16 Sep 2016 14:55:31 +0200
> @@ -1808,6 +1808,30 @@ static struct rt6_info *ip6_nh_lookup_table(struct net *net,
> return rt;
> }
>
> +static int ip6_nh_valid(struct rt6_info *grt,
> + struct net_device **dev, struct inet6_dev **idev) {
> + int ret = 0;
First, this is not formatted properly. The openning brace should start
on a new line.
Second, please use "bool", "true", and "false" for the return value.
Thanks.
^ permalink raw reply
* Re: [patch net-next v10 0/3] return offloaded stats as default and expose original sw stats
From: David Miller @ 2016-09-19 4:56 UTC (permalink / raw)
To: jiri
Cc: netdev, nogahf, idosch, eladr, yotamg, ogerlitz, roopa, nikolay,
linville, tgraf, gospo, sfeldma, sd, eranbe, ast, edumazet,
hannes, f.fainelli, dsa
In-Reply-To: <1474031138-2065-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 16 Sep 2016 15:05:35 +0200
> The problem we try to handle is about offloaded forwarded packets
> which are not seen by kernel. Let me try to draw it:
>
> port1 port2 (HW stats are counted here)
> \ /
> \ /
> \ /
> --(A)---- ASIC --(B)--
> |
> (C)
> |
> CPU (SW stats are counted here)
>
>
> Now we have couple of flows for TX and RX (direction does not matter here):
>
> 1) port1->A->ASIC->C->CPU
>
> For this flow, HW and SW stats are equal.
>
> 2) port1->A->ASIC->C->CPU->C->ASIC->B->port2
>
> For this flow, HW and SW stats are equal.
>
> 3) port1->A->ASIC->B->port2
>
> For this flow, SW stats are 0.
>
> The purpose of this patchset is to provide facility for user to
> find out the difference between flows 1+2 and 3. In other words, user
> will be able to see the statistics for the slow-path (through kernel).
...
Series applied, thanks Jiri.
^ 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