* [PATCH net-next 1/2] net/mlx5e: refactor indr setup block
@ 2019-12-10 10:08 wenxu
2019-12-10 10:08 ` [PATCH net-next 2/2] net/mlx5e: add mlx5e_rep_indr_setup_ft_cb support wenxu
0 siblings, 1 reply; 10+ messages in thread
From: wenxu @ 2019-12-10 10:08 UTC (permalink / raw)
To: paulb; +Cc: pablo, netdev
From: wenxu <wenxu@ucloud.cn>
Refactor indr setup block for support ft indr setup in the
next patch
Signed-off-by: wenxu <wenxu@ucloud.cn>
---
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 42 ++++++++++++------------
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
index f175cb2..6f304f6 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
@@ -710,9 +710,9 @@ static void mlx5e_rep_indr_clean_block_privs(struct mlx5e_rep_priv *rpriv)
static int
mlx5e_rep_indr_offload(struct net_device *netdev,
struct flow_cls_offload *flower,
- struct mlx5e_rep_indr_block_priv *indr_priv)
+ struct mlx5e_rep_indr_block_priv *indr_priv,
+ unsigned long flags)
{
- unsigned long flags = MLX5_TC_FLAG(EGRESS) | MLX5_TC_FLAG(ESW_OFFLOAD);
struct mlx5e_priv *priv = netdev_priv(indr_priv->rpriv->netdev);
int err = 0;
@@ -733,20 +733,22 @@ static void mlx5e_rep_indr_clean_block_privs(struct mlx5e_rep_priv *rpriv)
return err;
}
-static int mlx5e_rep_indr_setup_block_cb(enum tc_setup_type type,
- void *type_data, void *indr_priv)
+static int mlx5e_rep_indr_setup_tc_cb(enum tc_setup_type type,
+ void *type_data, void *indr_priv)
{
+ unsigned long flags = MLX5_TC_FLAG(EGRESS) | MLX5_TC_FLAG(ESW_OFFLOAD);
struct mlx5e_rep_indr_block_priv *priv = indr_priv;
switch (type) {
case TC_SETUP_CLSFLOWER:
- return mlx5e_rep_indr_offload(priv->netdev, type_data, priv);
+ return mlx5e_rep_indr_offload(priv->netdev, type_data, priv,
+ flags);
default:
return -EOPNOTSUPP;
}
}
-static void mlx5e_rep_indr_tc_block_unbind(void *cb_priv)
+static void mlx5e_rep_indr_block_unbind(void *cb_priv)
{
struct mlx5e_rep_indr_block_priv *indr_priv = cb_priv;
@@ -757,9 +759,10 @@ static void mlx5e_rep_indr_tc_block_unbind(void *cb_priv)
static LIST_HEAD(mlx5e_block_cb_list);
static int
-mlx5e_rep_indr_setup_tc_block(struct net_device *netdev,
- struct mlx5e_rep_priv *rpriv,
- struct flow_block_offload *f)
+mlx5e_rep_indr_setup_block(struct net_device *netdev,
+ struct mlx5e_rep_priv *rpriv,
+ struct flow_block_offload *f,
+ flow_setup_cb_t *setup_cb)
{
struct mlx5e_rep_indr_block_priv *indr_priv;
struct flow_block_cb *block_cb;
@@ -785,9 +788,8 @@ static void mlx5e_rep_indr_tc_block_unbind(void *cb_priv)
list_add(&indr_priv->list,
&rpriv->uplink_priv.tc_indr_block_priv_list);
- block_cb = flow_block_cb_alloc(mlx5e_rep_indr_setup_block_cb,
- indr_priv, indr_priv,
- mlx5e_rep_indr_tc_block_unbind);
+ block_cb = flow_block_cb_alloc(setup_cb, indr_priv, indr_priv,
+ mlx5e_rep_indr_block_unbind);
if (IS_ERR(block_cb)) {
list_del(&indr_priv->list);
kfree(indr_priv);
@@ -802,9 +804,7 @@ static void mlx5e_rep_indr_tc_block_unbind(void *cb_priv)
if (!indr_priv)
return -ENOENT;
- block_cb = flow_block_cb_lookup(f->block,
- mlx5e_rep_indr_setup_block_cb,
- indr_priv);
+ block_cb = flow_block_cb_lookup(f->block, setup_cb, indr_priv);
if (!block_cb)
return -ENOENT;
@@ -818,13 +818,13 @@ static void mlx5e_rep_indr_tc_block_unbind(void *cb_priv)
}
static
-int mlx5e_rep_indr_setup_tc_cb(struct net_device *netdev, void *cb_priv,
- enum tc_setup_type type, void *type_data)
+int mlx5e_rep_indr_setup_cb(struct net_device *netdev, void *cb_priv,
+ enum tc_setup_type type, void *type_data)
{
switch (type) {
case TC_SETUP_BLOCK:
- return mlx5e_rep_indr_setup_tc_block(netdev, cb_priv,
- type_data);
+ return mlx5e_rep_indr_setup_block(netdev, cb_priv, type_data,
+ mlx5e_rep_indr_setup_tc_cb);
default:
return -EOPNOTSUPP;
}
@@ -836,7 +836,7 @@ static int mlx5e_rep_indr_register_block(struct mlx5e_rep_priv *rpriv,
int err;
err = __flow_indr_block_cb_register(netdev, rpriv,
- mlx5e_rep_indr_setup_tc_cb,
+ mlx5e_rep_indr_setup_cb,
rpriv);
if (err) {
struct mlx5e_priv *priv = netdev_priv(rpriv->netdev);
@@ -850,7 +850,7 @@ static int mlx5e_rep_indr_register_block(struct mlx5e_rep_priv *rpriv,
static void mlx5e_rep_indr_unregister_block(struct mlx5e_rep_priv *rpriv,
struct net_device *netdev)
{
- __flow_indr_block_cb_unregister(netdev, mlx5e_rep_indr_setup_tc_cb,
+ __flow_indr_block_cb_unregister(netdev, mlx5e_rep_indr_setup_cb,
rpriv);
}
--
1.8.3.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH net-next 2/2] net/mlx5e: add mlx5e_rep_indr_setup_ft_cb support
2019-12-10 10:08 [PATCH net-next 1/2] net/mlx5e: refactor indr setup block wenxu
@ 2019-12-10 10:08 ` wenxu
2019-12-10 11:44 ` Paul Blakey
0 siblings, 1 reply; 10+ messages in thread
From: wenxu @ 2019-12-10 10:08 UTC (permalink / raw)
To: paulb; +Cc: pablo, netdev
From: wenxu <wenxu@ucloud.cn>
Add mlx5e_rep_indr_setup_ft_cb to support indr block setup
in FT mode.
Signed-off-by: wenxu <wenxu@ucloud.cn>
---
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 37 ++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
index 6f304f6..e0da17c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
@@ -748,6 +748,40 @@ static int mlx5e_rep_indr_setup_tc_cb(enum tc_setup_type type,
}
}
+static int mlx5e_rep_indr_setup_ft_cb(enum tc_setup_type type,
+ void *type_data, void *indr_priv)
+{
+ struct mlx5e_rep_indr_block_priv *priv = indr_priv;
+ struct mlx5e_priv *mpriv = netdev_priv(priv->rpriv->netdev);
+ struct mlx5_eswitch *esw = mpriv->mdev->priv.eswitch;
+ struct flow_cls_offload *f = type_data;
+ struct flow_cls_offload cls_flower;
+ unsigned long flags;
+ int err;
+
+ flags = MLX5_TC_FLAG(EGRESS) |
+ MLX5_TC_FLAG(ESW_OFFLOAD) |
+ MLX5_TC_FLAG(FT_OFFLOAD);
+
+ switch (type) {
+ case TC_SETUP_CLSFLOWER:
+ if (!mlx5_eswitch_prios_supported(esw) || f->common.chain_index)
+ return -EOPNOTSUPP;
+
+ /* Re-use tc offload path by moving the ft flow to the
+ * reserved ft chain.
+ */
+ memcpy(&cls_flower, f, sizeof(*f));
+ cls_flower.common.chain_index = FDB_FT_CHAIN;
+ err = mlx5e_rep_indr_offload(priv->netdev, &cls_flower, priv,
+ flags);
+ memcpy(&f->stats, &cls_flower.stats, sizeof(f->stats));
+ return err;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
static void mlx5e_rep_indr_block_unbind(void *cb_priv)
{
struct mlx5e_rep_indr_block_priv *indr_priv = cb_priv;
@@ -825,6 +859,9 @@ int mlx5e_rep_indr_setup_cb(struct net_device *netdev, void *cb_priv,
case TC_SETUP_BLOCK:
return mlx5e_rep_indr_setup_block(netdev, cb_priv, type_data,
mlx5e_rep_indr_setup_tc_cb);
+ case TC_SETUP_FT:
+ return mlx5e_rep_indr_setup_block(netdev, cb_priv, type_data,
+ mlx5e_rep_indr_setup_ft_cb);
default:
return -EOPNOTSUPP;
}
--
1.8.3.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH net-next 2/2] net/mlx5e: add mlx5e_rep_indr_setup_ft_cb support
2019-12-10 10:08 ` [PATCH net-next 2/2] net/mlx5e: add mlx5e_rep_indr_setup_ft_cb support wenxu
@ 2019-12-10 11:44 ` Paul Blakey
2019-12-11 2:41 ` wenxu
0 siblings, 1 reply; 10+ messages in thread
From: Paul Blakey @ 2019-12-10 11:44 UTC (permalink / raw)
To: wenxu; +Cc: pablo, netdev
On 12/10/2019 12:08 PM, wenxu@ucloud.cn wrote:
> From: wenxu <wenxu@ucloud.cn>
>
> Add mlx5e_rep_indr_setup_ft_cb to support indr block setup
> in FT mode.
>
> Signed-off-by: wenxu <wenxu@ucloud.cn>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 37 ++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
> index 6f304f6..e0da17c 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
> @@ -748,6 +748,40 @@ static int mlx5e_rep_indr_setup_tc_cb(enum tc_setup_type type,
> }
> }
>
> +static int mlx5e_rep_indr_setup_ft_cb(enum tc_setup_type type,
> + void *type_data, void *indr_priv)
> +{
> + struct mlx5e_rep_indr_block_priv *priv = indr_priv;
> + struct mlx5e_priv *mpriv = netdev_priv(priv->rpriv->netdev);
> + struct mlx5_eswitch *esw = mpriv->mdev->priv.eswitch;
> + struct flow_cls_offload *f = type_data;
> + struct flow_cls_offload cls_flower;
> + unsigned long flags;
> + int err;
> +
> + flags = MLX5_TC_FLAG(EGRESS) |
> + MLX5_TC_FLAG(ESW_OFFLOAD) |
> + MLX5_TC_FLAG(FT_OFFLOAD);
> +
> + switch (type) {
> + case TC_SETUP_CLSFLOWER:
> + if (!mlx5_eswitch_prios_supported(esw) || f->common.chain_index)
> + return -EOPNOTSUPP;
> +
> + /* Re-use tc offload path by moving the ft flow to the
> + * reserved ft chain.
> + */
> + memcpy(&cls_flower, f, sizeof(*f));
> + cls_flower.common.chain_index = FDB_FT_CHAIN;
> + err = mlx5e_rep_indr_offload(priv->netdev, &cls_flower, priv,
> + flags);
> + memcpy(&f->stats, &cls_flower.stats, sizeof(f->stats));
> + return err;
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +
> static void mlx5e_rep_indr_block_unbind(void *cb_priv)
> {
> struct mlx5e_rep_indr_block_priv *indr_priv = cb_priv;
> @@ -825,6 +859,9 @@ int mlx5e_rep_indr_setup_cb(struct net_device *netdev, void *cb_priv,
> case TC_SETUP_BLOCK:
> return mlx5e_rep_indr_setup_block(netdev, cb_priv, type_data,
> mlx5e_rep_indr_setup_tc_cb);
> + case TC_SETUP_FT:
> + return mlx5e_rep_indr_setup_block(netdev, cb_priv, type_data,
> + mlx5e_rep_indr_setup_ft_cb);
> default:
> return -EOPNOTSUPP;
> }
+cc Saeed
This looks good to me, but it should be on top of a patch that will
actual allows the indirect BIND if the nft
table device is a tunnel device. Is that upstream? If so which patch?
Currently (5.5.0-rc1+), nft_register_flowtable_net_hooks calls
nf_flow_table_offload_setup which will see
that the tunnel device doesn't have ndo_setup_tc and return
-EOPNOTSUPPORTED.
Thanks,
Paul.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH net-next 2/2] net/mlx5e: add mlx5e_rep_indr_setup_ft_cb support
2019-12-10 11:44 ` Paul Blakey
@ 2019-12-11 2:41 ` wenxu
2019-12-11 8:18 ` Paul Blakey
2019-12-17 19:54 ` Saeed Mahameed
0 siblings, 2 replies; 10+ messages in thread
From: wenxu @ 2019-12-11 2:41 UTC (permalink / raw)
To: Paul Blakey, pablo; +Cc: netdev, Saeed Mahameed
On 12/10/2019 7:44 PM, Paul Blakey wrote:
> On 12/10/2019 12:08 PM, wenxu@ucloud.cn wrote:
>> From: wenxu <wenxu@ucloud.cn>
>>
>> Add mlx5e_rep_indr_setup_ft_cb to support indr block setup
>> in FT mode.
>>
>> Signed-off-by: wenxu <wenxu@ucloud.cn>
>> ---
>> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 37 ++++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
>> index 6f304f6..e0da17c 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
>> @@ -748,6 +748,40 @@ static int mlx5e_rep_indr_setup_tc_cb(enum tc_setup_type type,
>> }
>> }
>>
>> +static int mlx5e_rep_indr_setup_ft_cb(enum tc_setup_type type,
>> + void *type_data, void *indr_priv)
>> +{
>> + struct mlx5e_rep_indr_block_priv *priv = indr_priv;
>> + struct mlx5e_priv *mpriv = netdev_priv(priv->rpriv->netdev);
>> + struct mlx5_eswitch *esw = mpriv->mdev->priv.eswitch;
>> + struct flow_cls_offload *f = type_data;
>> + struct flow_cls_offload cls_flower;
>> + unsigned long flags;
>> + int err;
>> +
>> + flags = MLX5_TC_FLAG(EGRESS) |
>> + MLX5_TC_FLAG(ESW_OFFLOAD) |
>> + MLX5_TC_FLAG(FT_OFFLOAD);
>> +
>> + switch (type) {
>> + case TC_SETUP_CLSFLOWER:
>> + if (!mlx5_eswitch_prios_supported(esw) || f->common.chain_index)
>> + return -EOPNOTSUPP;
>> +
>> + /* Re-use tc offload path by moving the ft flow to the
>> + * reserved ft chain.
>> + */
>> + memcpy(&cls_flower, f, sizeof(*f));
>> + cls_flower.common.chain_index = FDB_FT_CHAIN;
>> + err = mlx5e_rep_indr_offload(priv->netdev, &cls_flower, priv,
>> + flags);
>> + memcpy(&f->stats, &cls_flower.stats, sizeof(f->stats));
>> + return err;
>> + default:
>> + return -EOPNOTSUPP;
>> + }
>> +}
>> +
>> static void mlx5e_rep_indr_block_unbind(void *cb_priv)
>> {
>> struct mlx5e_rep_indr_block_priv *indr_priv = cb_priv;
>> @@ -825,6 +859,9 @@ int mlx5e_rep_indr_setup_cb(struct net_device *netdev, void *cb_priv,
>> case TC_SETUP_BLOCK:
>> return mlx5e_rep_indr_setup_block(netdev, cb_priv, type_data,
>> mlx5e_rep_indr_setup_tc_cb);
>> + case TC_SETUP_FT:
>> + return mlx5e_rep_indr_setup_block(netdev, cb_priv, type_data,
>> + mlx5e_rep_indr_setup_ft_cb);
>> default:
>> return -EOPNOTSUPP;
>> }
>
> +cc Saeed
>
>
> This looks good to me, but it should be on top of a patch that will
> actual allows the indirect BIND if the nft
>
> table device is a tunnel device. Is that upstream? If so which patch?
>
>
> Currently (5.5.0-rc1+), nft_register_flowtable_net_hooks calls
> nf_flow_table_offload_setup which will see
>
> that the tunnel device doesn't have ndo_setup_tc and return
> -EOPNOTSUPPORTED.
The related patch http://patchwork.ozlabs.org/patch/1206935/
is waiting for upstream
>
> Thanks,
>
> Paul.
>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH net-next 2/2] net/mlx5e: add mlx5e_rep_indr_setup_ft_cb support
2019-12-11 2:41 ` wenxu
@ 2019-12-11 8:18 ` Paul Blakey
2019-12-17 19:54 ` Saeed Mahameed
1 sibling, 0 replies; 10+ messages in thread
From: Paul Blakey @ 2019-12-11 8:18 UTC (permalink / raw)
To: wenxu, pablo; +Cc: netdev, Saeed Mahameed
On 12/11/2019 4:41 AM, wenxu wrote:
> On 12/10/2019 7:44 PM, Paul Blakey wrote:
>> On 12/10/2019 12:08 PM, wenxu@ucloud.cn wrote:
>>> From: wenxu <wenxu@ucloud.cn>
>>>
>>> Add mlx5e_rep_indr_setup_ft_cb to support indr block setup
>>> in FT mode.
>>>
>>> Signed-off-by: wenxu <wenxu@ucloud.cn>
>>> ---
>>> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 37 ++++++++++++++++++++++++
>>> 1 file changed, 37 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
>>> index 6f304f6..e0da17c 100644
>>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
>>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
>>> @@ -748,6 +748,40 @@ static int mlx5e_rep_indr_setup_tc_cb(enum tc_setup_type type,
>>> }
>>> }
>>>
>>> +static int mlx5e_rep_indr_setup_ft_cb(enum tc_setup_type type,
>>> + void *type_data, void *indr_priv)
>>> +{
>>> + struct mlx5e_rep_indr_block_priv *priv = indr_priv;
>>> + struct mlx5e_priv *mpriv = netdev_priv(priv->rpriv->netdev);
>>> + struct mlx5_eswitch *esw = mpriv->mdev->priv.eswitch;
>>> + struct flow_cls_offload *f = type_data;
>>> + struct flow_cls_offload cls_flower;
>>> + unsigned long flags;
>>> + int err;
>>> +
>>> + flags = MLX5_TC_FLAG(EGRESS) |
>>> + MLX5_TC_FLAG(ESW_OFFLOAD) |
>>> + MLX5_TC_FLAG(FT_OFFLOAD);
>>> +
>>> + switch (type) {
>>> + case TC_SETUP_CLSFLOWER:
>>> + if (!mlx5_eswitch_prios_supported(esw) || f->common.chain_index)
>>> + return -EOPNOTSUPP;
>>> +
>>> + /* Re-use tc offload path by moving the ft flow to the
>>> + * reserved ft chain.
>>> + */
>>> + memcpy(&cls_flower, f, sizeof(*f));
>>> + cls_flower.common.chain_index = FDB_FT_CHAIN;
>>> + err = mlx5e_rep_indr_offload(priv->netdev, &cls_flower, priv,
>>> + flags);
>>> + memcpy(&f->stats, &cls_flower.stats, sizeof(f->stats));
>>> + return err;
>>> + default:
>>> + return -EOPNOTSUPP;
>>> + }
>>> +}
>>> +
>>> static void mlx5e_rep_indr_block_unbind(void *cb_priv)
>>> {
>>> struct mlx5e_rep_indr_block_priv *indr_priv = cb_priv;
>>> @@ -825,6 +859,9 @@ int mlx5e_rep_indr_setup_cb(struct net_device *netdev, void *cb_priv,
>>> case TC_SETUP_BLOCK:
>>> return mlx5e_rep_indr_setup_block(netdev, cb_priv, type_data,
>>> mlx5e_rep_indr_setup_tc_cb);
>>> + case TC_SETUP_FT:
>>> + return mlx5e_rep_indr_setup_block(netdev, cb_priv, type_data,
>>> + mlx5e_rep_indr_setup_ft_cb);
>>> default:
>>> return -EOPNOTSUPP;
>>> }
>> +cc Saeed
>>
>>
>> This looks good to me, but it should be on top of a patch that will
>> actual allows the indirect BIND if the nft
>>
>> table device is a tunnel device. Is that upstream? If so which patch?
>>
>>
>> Currently (5.5.0-rc1+), nft_register_flowtable_net_hooks calls
>> nf_flow_table_offload_setup which will see
>>
>> that the tunnel device doesn't have ndo_setup_tc and return
>> -EOPNOTSUPPORTED.
> The related patch http://patchwork.ozlabs.org/patch/1206935/
>
> is waiting for upstream
I see, thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH net-next 2/2] net/mlx5e: add mlx5e_rep_indr_setup_ft_cb support
2019-12-11 2:41 ` wenxu
2019-12-11 8:18 ` Paul Blakey
@ 2019-12-17 19:54 ` Saeed Mahameed
2020-03-16 3:14 ` wenxu
1 sibling, 1 reply; 10+ messages in thread
From: Saeed Mahameed @ 2019-12-17 19:54 UTC (permalink / raw)
To: wenxu, Paul Blakey, pablo; +Cc: netdev
On Wed, 2019-12-11 at 10:41 +0800, wenxu wrote:
> On 12/10/2019 7:44 PM, Paul Blakey wrote:
> > On 12/10/2019 12:08 PM, wenxu@ucloud.cn wrote:
> > > From: wenxu <wenxu@ucloud.cn>
> > >
> > > Add mlx5e_rep_indr_setup_ft_cb to support indr block setup
> > > in FT mode.
> > >
> > > Signed-off-by: wenxu <wenxu@ucloud.cn>
> > > ---
[...]
> > +cc Saeed
> >
> >
> > This looks good to me, but it should be on top of a patch that
> > will
> > actual allows the indirect BIND if the nft
> >
> > table device is a tunnel device. Is that upstream? If so which
> > patch?
> >
> >
> > Currently (5.5.0-rc1+), nft_register_flowtable_net_hooks calls
> > nf_flow_table_offload_setup which will see
> >
> > that the tunnel device doesn't have ndo_setup_tc and return
> > -EOPNOTSUPPORTED.
>
> The related patch http://patchwork.ozlabs.org/patch/1206935/
>
> is waiting for upstream
>
The netfilter patch is still under-review, once accepted i will apply
this series.
Thanks,
Saeed.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH net-next 2/2] net/mlx5e: add mlx5e_rep_indr_setup_ft_cb support
2019-12-17 19:54 ` Saeed Mahameed
@ 2020-03-16 3:14 ` wenxu
2020-03-18 3:59 ` Saeed Mahameed
0 siblings, 1 reply; 10+ messages in thread
From: wenxu @ 2020-03-16 3:14 UTC (permalink / raw)
To: Saeed Mahameed, Paul Blakey; +Cc: netdev
On 12/18/2019 3:54 AM, Saeed Mahameed wrote:
> On Wed, 2019-12-11 at 10:41 +0800, wenxu wrote:
>> On 12/10/2019 7:44 PM, Paul Blakey wrote:
>>> On 12/10/2019 12:08 PM, wenxu@ucloud.cn wrote:
>>>> From: wenxu <wenxu@ucloud.cn>
>>>>
>>>> Add mlx5e_rep_indr_setup_ft_cb to support indr block setup
>>>> in FT mode.
>>>>
>>>> Signed-off-by: wenxu <wenxu@ucloud.cn>
>>>> ---
> [...]
>
>>> +cc Saeed
>>>
>>>
>>> This looks good to me, but it should be on top of a patch that
>>> will
>>> actual allows the indirect BIND if the nft
>>>
>>> table device is a tunnel device. Is that upstream? If so which
>>> patch?
>>>
>>>
>>> Currently (5.5.0-rc1+), nft_register_flowtable_net_hooks calls
>>> nf_flow_table_offload_setup which will see
>>>
>>> that the tunnel device doesn't have ndo_setup_tc and return
>>> -EOPNOTSUPPORTED.
>> The related patch http://patchwork.ozlabs.org/patch/1206935/
>>
>> is waiting for upstream
>>
> The netfilter patch is still under-review, once accepted i will apply
> this series.
>
> Thanks,
> Saeed.
>
Hi Saeed,
Sorry for so long time to update. The netfilter patch is already accepted. This series is also
not out of date and can apply to net-next. If you feel ok please apply it thanks.
The netfilter patch:
http://patchwork.ozlabs.org/patch/1242815/
BR
wenxu
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH net-next 2/2] net/mlx5e: add mlx5e_rep_indr_setup_ft_cb support
2020-03-16 3:14 ` wenxu
@ 2020-03-18 3:59 ` Saeed Mahameed
2020-03-18 4:05 ` Saeed Mahameed
0 siblings, 1 reply; 10+ messages in thread
From: Saeed Mahameed @ 2020-03-18 3:59 UTC (permalink / raw)
To: wenxu, Paul Blakey; +Cc: netdev
On Mon, 2020-03-16 at 11:14 +0800, wenxu wrote:
> On 12/18/2019 3:54 AM, Saeed Mahameed wrote:
> > On Wed, 2019-12-11 at 10:41 +0800, wenxu wrote:
> > > On 12/10/2019 7:44 PM, Paul Blakey wrote:
> > > > On 12/10/2019 12:08 PM, wenxu@ucloud.cn wrote:
> > > > > From: wenxu <wenxu@ucloud.cn>
> > > > >
> > > > > Add mlx5e_rep_indr_setup_ft_cb to support indr block setup
> > > > > in FT mode.
> > > > >
> > > > > Signed-off-by: wenxu <wenxu@ucloud.cn>
> > > > > ---
> > [...]
> >
> > > > +cc Saeed
> > > >
> > > >
> > > > This looks good to me, but it should be on top of a patch that
> > > > will
> > > > actual allows the indirect BIND if the nft
> > > >
> > > > table device is a tunnel device. Is that upstream? If so which
> > > > patch?
> > > >
> > > >
> > > > Currently (5.5.0-rc1+), nft_register_flowtable_net_hooks calls
> > > > nf_flow_table_offload_setup which will see
> > > >
> > > > that the tunnel device doesn't have ndo_setup_tc and return
> > > > -EOPNOTSUPPORTED.
> > > The related patch http://patchwork.ozlabs.org/patch/1206935/
> > >
> > > is waiting for upstream
> > >
> > The netfilter patch is still under-review, once accepted i will
> > apply
> > this series.
> >
> > Thanks,
> > Saeed.
> >
> Hi Saeed,
>
>
> Sorry for so long time to update. The netfilter patch is already
> accepted. This series is also
>
> not out of date and can apply to net-next. If you feel ok please
> apply it thanks.
>
>
> The netfilter patch:
>
> http://patchwork.ozlabs.org/patch/1242815/
>
> BR
>
> wenxu
>
Applied to net-next-mlx5, doing some build testing now, and will make
this run in regression for a couple of days until my next pull request
to net-next.
Thanks,
saeed.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH net-next 2/2] net/mlx5e: add mlx5e_rep_indr_setup_ft_cb support
2020-03-18 3:59 ` Saeed Mahameed
@ 2020-03-18 4:05 ` Saeed Mahameed
2020-03-18 5:49 ` wenxu
0 siblings, 1 reply; 10+ messages in thread
From: Saeed Mahameed @ 2020-03-18 4:05 UTC (permalink / raw)
To: wenxu, Paul Blakey; +Cc: netdev
On Tue, 2020-03-17 at 20:58 -0700, Saeed Mahameed wrote:
> On Mon, 2020-03-16 at 11:14 +0800, wenxu wrote:
> > On 12/18/2019 3:54 AM, Saeed Mahameed wrote:
> > > On Wed, 2019-12-11 at 10:41 +0800, wenxu wrote:
> > > > On 12/10/2019 7:44 PM, Paul Blakey wrote:
> > > > > On 12/10/2019 12:08 PM, wenxu@ucloud.cn wrote:
> > > > > > From: wenxu <wenxu@ucloud.cn>
> > > > > >
> > > > > > Add mlx5e_rep_indr_setup_ft_cb to support indr block setup
> > > > > > in FT mode.
> > > > > >
> > > > > > Signed-off-by: wenxu <wenxu@ucloud.cn>
> > > > > > ---
> > > [...]
> > >
> > > > > +cc Saeed
> > > > >
> > > > >
> > > > > This looks good to me, but it should be on top of a patch
> > > > > that
> > > > > will
> > > > > actual allows the indirect BIND if the nft
> > > > >
> > > > > table device is a tunnel device. Is that upstream? If so
> > > > > which
> > > > > patch?
> > > > >
> > > > >
> > > > > Currently (5.5.0-rc1+), nft_register_flowtable_net_hooks
> > > > > calls
> > > > > nf_flow_table_offload_setup which will see
> > > > >
> > > > > that the tunnel device doesn't have ndo_setup_tc and return
> > > > > -EOPNOTSUPPORTED.
> > > > The related patch http://patchwork.ozlabs.org/patch/1206935/
> > > >
> > > > is waiting for upstream
> > > >
> > > The netfilter patch is still under-review, once accepted i will
> > > apply
> > > this series.
> > >
> > > Thanks,
> > > Saeed.
> > >
> > Hi Saeed,
> >
> >
> > Sorry for so long time to update. The netfilter patch is already
> > accepted. This series is also
> >
> > not out of date and can apply to net-next. If you feel ok please
> > apply it thanks.
> >
> >
> > The netfilter patch:
> >
> > http://patchwork.ozlabs.org/patch/1242815/
> >
> > BR
> >
> > wenxu
> >
>
> Applied to net-next-mlx5, doing some build testing now, and will
> make
> this run in regression for a couple of days until my next pull
> request
> to net-next.
>
hmmm, i was too optimistic, patches got blocked by CI, apparently some
changes in mlx5 eswitch API are causing the following failure, most
likely due to the introduction of eswitch_chains API.
05:57:47 make -s -j 96 CC=/usr/llvm/bin/clang
drivers/net/ethernet/mellanox/mlx5/core/
05:58:14 error: drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:752:8:
error: implicit declaration of function 'mlx5_eswitch_prios_supported'
[-Werror,-Wimplicit-function-declaration]
05:58:14 error: drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:752:8:
note: did you mean 'mlx5_esw_chains_prios_supported'?
05:58:14
Please rebase and re-test, I can help you with more details if you
need.
Thanks,
Saeed.
> Thanks,
> saeed.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH net-next 2/2] net/mlx5e: add mlx5e_rep_indr_setup_ft_cb support
2020-03-18 4:05 ` Saeed Mahameed
@ 2020-03-18 5:49 ` wenxu
0 siblings, 0 replies; 10+ messages in thread
From: wenxu @ 2020-03-18 5:49 UTC (permalink / raw)
To: Saeed Mahameed, Paul Blakey; +Cc: netdev
On 3/18/2020 12:05 PM, Saeed Mahameed wrote:
> On Tue, 2020-03-17 at 20:58 -0700, Saeed Mahameed wrote:
>> On Mon, 2020-03-16 at 11:14 +0800, wenxu wrote:
>>> On 12/18/2019 3:54 AM, Saeed Mahameed wrote:
>>>> On Wed, 2019-12-11 at 10:41 +0800, wenxu wrote:
>>>>> On 12/10/2019 7:44 PM, Paul Blakey wrote:
>>>>>> On 12/10/2019 12:08 PM, wenxu@ucloud.cn wrote:
>>>>>>> From: wenxu <wenxu@ucloud.cn>
>>>>>>>
>>>>>>> Add mlx5e_rep_indr_setup_ft_cb to support indr block setup
>>>>>>> in FT mode.
>>>>>>>
>>>>>>> Signed-off-by: wenxu <wenxu@ucloud.cn>
>>>>>>> ---
>>>> [...]
>>>>
>>>>>> +cc Saeed
>>>>>>
>>>>>>
>>>>>> This looks good to me, but it should be on top of a patch
>>>>>> that
>>>>>> will
>>>>>> actual allows the indirect BIND if the nft
>>>>>>
>>>>>> table device is a tunnel device. Is that upstream? If so
>>>>>> which
>>>>>> patch?
>>>>>>
>>>>>>
>>>>>> Currently (5.5.0-rc1+), nft_register_flowtable_net_hooks
>>>>>> calls
>>>>>> nf_flow_table_offload_setup which will see
>>>>>>
>>>>>> that the tunnel device doesn't have ndo_setup_tc and return
>>>>>> -EOPNOTSUPPORTED.
>>>>> The related patch http://patchwork.ozlabs.org/patch/1206935/
>>>>>
>>>>> is waiting for upstream
>>>>>
>>>> The netfilter patch is still under-review, once accepted i will
>>>> apply
>>>> this series.
>>>>
>>>> Thanks,
>>>> Saeed.
>>>>
>>> Hi Saeed,
>>>
>>>
>>> Sorry for so long time to update. The netfilter patch is already
>>> accepted. This series is also
>>>
>>> not out of date and can apply to net-next. If you feel ok please
>>> apply it thanks.
>>>
>>>
>>> The netfilter patch:
>>>
>>> http://patchwork.ozlabs.org/patch/1242815/
>>>
>>> BR
>>>
>>> wenxu
>>>
>> Applied to net-next-mlx5, doing some build testing now, and will
>> make
>> this run in regression for a couple of days until my next pull
>> request
>> to net-next.
>>
> hmmm, i was too optimistic, patches got blocked by CI, apparently some
> changes in mlx5 eswitch API are causing the following failure, most
> likely due to the introduction of eswitch_chains API.
>
> 05:57:47 make -s -j 96 CC=/usr/llvm/bin/clang
> drivers/net/ethernet/mellanox/mlx5/core/
> 05:58:14 error: drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:752:8:
> error: implicit declaration of function 'mlx5_eswitch_prios_supported'
> [-Werror,-Wimplicit-function-declaration]
> 05:58:14 error: drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:752:8:
> note: did you mean 'mlx5_esw_chains_prios_supported'?
> 05:58:14
>
>
> Please rebase and re-test, I can help you with more details if you
> need.
Will do.
> Thanks,
> Saeed.
>
>> Thanks,
>> saeed.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-03-18 5:49 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-10 10:08 [PATCH net-next 1/2] net/mlx5e: refactor indr setup block wenxu
2019-12-10 10:08 ` [PATCH net-next 2/2] net/mlx5e: add mlx5e_rep_indr_setup_ft_cb support wenxu
2019-12-10 11:44 ` Paul Blakey
2019-12-11 2:41 ` wenxu
2019-12-11 8:18 ` Paul Blakey
2019-12-17 19:54 ` Saeed Mahameed
2020-03-16 3:14 ` wenxu
2020-03-18 3:59 ` Saeed Mahameed
2020-03-18 4:05 ` Saeed Mahameed
2020-03-18 5:49 ` wenxu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.