* Re: [PATCH net v2] mlx4: Return EOPNOTSUPP instead of ENOTSUPP
From: Martin KaFai Lau @ 2017-01-10 22:36 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Linux Netdev List, Saeed Mahameed, Tariq Toukan, Kernel Team
In-Reply-To: <CALzJLG99semMYGKMO1QvNg1EK0m-uFWv4+-o45oV9t3QoY6_rw@mail.gmail.com>
On Tue, Jan 10, 2017 at 10:04:55PM +0200, Saeed Mahameed wrote:
> On Tue, Jan 10, 2017 at 7:41 PM, Martin KaFai Lau <kafai@fb.com> wrote:
> > In commit b45f0674b997 ("mlx4: xdp: Allow raising MTU up to one page minus eth and vlan hdrs"),
> > it changed EOPNOTSUPP to ENOTSUPP by mistake. This patch fixes it.
> >
> > Fixes: b45f0674b997 ("mlx4: xdp: Allow raising MTU up to one page minus eth and vlan hdrs")
> > Signed-off-by: Martin KaFai Lau <kafai@fb.com>
>
> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
>
>
> Thank you martin.
>
> Small question though,
> is it essential for the upper layer to get the correct errno ? or this
> is just a cleanup ?
Former. probably for the netlink's NLMSG_ERROR also.
^ permalink raw reply
* Re: [PATCH net-next 6/8] net: dsa: Add support for platform data
From: Florian Fainelli @ 2017-01-10 22:15 UTC (permalink / raw)
To: Andrew Lunn, John Crispin
Cc: netdev, Jason Cooper, Sebastian Hesselbarth, Gregory Clement,
Russell King, Vivien Didelot, David S. Miller, Philippe Reynes,
Martin Schwidefsky, Greg Kroah-Hartman, Stuart Yoder,
Ingo Tuchscherer,
moderated list:ARM/Marvell Dove/MV78xx0/Orion SOC support,
open list
In-Reply-To: <20170110212117.GO22820@lunn.ch>
On 01/10/2017 01:21 PM, Andrew Lunn wrote:
>> Last time we discussed this, I had a super complex dsa2_platform_data
>> that allowed you to do exactly the same thing we currently do with
>> Device Tree, except that this was with platform_data. It took a lot of
>> effort to get there, but I essentially had the ZII vf160 board example
>> re-implemented and verified with a mockup driver (still have it in a
>> branch that's not too far from net-next/master).
>
> One thing different this time is you have associated the platform data
> to an MDIO device. So the platform data represents one switch, not the
> whole complex. This is going to make the platform data much simpler,
> and allow the core to do the work of assembling the multiple platform
> datas into one switch complex. So basically, the platform data is
> dsa_chip_data.
>
> To handle multi-CPUs, we need to move the master ethernet device and
> put it next to the cpu port. So add a
>
> struct device *netdev[DSA_MAX_PORTS];
>
> to dsa_chip_data. It then becomes easy to represent multiple CPU
> ports.
Alright, let me get that prepared then, thanks!
>
>> I would very much like to see the patches and then make a decision based
>> on the submission rather than project a decision on code that has not
>> been submitted yet.
>
> The first version was posted a week ago. I requested a lot of
> changes. So lets see what John says about when the next version will
> be ready.
Oh that series, okay, somehow I thought you were referring to something
else.
--
Florian
^ permalink raw reply
* Re: [net-next PATCH 1/3] Revert "icmp: avoid allocating large struct on stack"
From: Eric Dumazet @ 2017-01-10 21:48 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Cong Wang, David Miller, Linux Kernel Network Developers
In-Reply-To: <20170110210820.1c5dbc87@redhat.com>
On Tue, 2017-01-10 at 21:08 +0100, Jesper Dangaard Brouer wrote:
> On Tue, 10 Jan 2017 10:44:59 -0800 Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
> > On Tue, Jan 10, 2017 at 10:12 AM, David Miller <davem@davemloft.net> wrote:
> [...]
> > > You can keep showing us how expertly you can deflect the real
> > > issue we are discussion here, but that won't improve the situation
> > > at all I am afraid.
> >
> > Of course, there are just too many people too lazy to do a google search:
> >
> > https://lists.debian.org/debian-kernel/2013/05/msg00500.html
>
> My analysis of the problem shown in above link is not related to using
> all the stack space, but instead that skb->cb was not cleared. This
> can cause the ip_options_echo() call in icmp_send() to access garbage
> as this is: __ip_options_echo(dopt, skb, &IPCB(skb)->opt).
>
> Fixed by commit a622260254ee ("ip_tunnel: fix kernel panic with icmp_dest_unreach")
> https://git.kernel.org/torvalds/c/a622260254ee
>
> Thus, it is (likely) the __ip_options_echo() call that violates stack
> access, as it is passed in a pointer to the stack, and advance this
> based on garbage "optlen".
>
I totally agree.
This can not be stack being too small in current kernels.
> #0 [ffff88003fd03798] machine_kexec at ffffffff81027430
> #1 [ffff88003fd037e8] crash_kexec at ffffffff8107da80
> #2 [ffff88003fd038b8] panic at ffffffff81540026
> #3 [ffff88003fd03938] __stack_chk_fail at ffffffff81037f77
> #4 [ffff88003fd03948] icmp_send at ffffffff814d5fec
> #5 [ffff88003fd03b78] dev_hard_start_xmit at ffffffff8146e032
> #6 [ffff88003fd03bc8] sch_direct_xmit at ffffffff81487d66
> #7 [ffff88003fd03c08] __qdisc_run at ffffffff81487efd
> #8 [ffff88003fd03c48] dev_queue_xmit at ffffffff8146e5a7
> #9 [ffff88003fd03c88] ip_finish_output at ffffffff814ab596
> #10 [ffff88003fd03ce8] __netif_receive_skb at ffffffff8146ed13
> #11 [ffff88003fd03d88] napi_gro_receive at ffffffff8146fc50
> #12 [ffff88003fd03da8] e1000_clean_rx_irq at ffffffff813bc67b
> #13 [ffff88003fd03e48] e1000e_poll at ffffffff813c3a20
> #14 [ffff88003fd03e98] net_rx_action at ffffffff8146f796
> #15 [ffff88003fd03ee8] __do_softirq at ffffffff8103ebb9
> #16 [ffff88003fd03f38] call_softirq at ffffffff8154444c
> #17 [ffff88003fd03f50] do_softirq at ffffffff810047dd
> #18 [ffff88003fd03f80] do_IRQ at ffffffff81003f6c
Total stack used is about 3FFF - 3938, which is less than 2KB.
x86_64 is supposed to have at least 16 KB irq stacks.
^ permalink raw reply
* Re: [net-next PATCH 1/3] Revert "icmp: avoid allocating large struct on stack"
From: Joe Perches @ 2017-01-10 21:41 UTC (permalink / raw)
To: David Miller, xiyou.wangcong; +Cc: eric.dumazet, brouer, netdev
In-Reply-To: <20170110.131223.748150430551443881.davem@davemloft.net>
On Tue, 2017-01-10 at 13:12 -0500, David Miller wrote:
> From: Cong Wang <xiyou.wangcong@gmail.com>
> Date: Tue, 10 Jan 2017 10:06:01 -0800
>
> > On Mon, Jan 9, 2017 at 10:52 AM, David Miller <davem@davemloft.net> wrote:
> >> From: Eric Dumazet <eric.dumazet@gmail.com>
> >> Date: Mon, 09 Jan 2017 10:07:04 -0800
> >>
> >>> You really should come to netdev conferences so that you understand
> >>> goals and efforts, instead of living in your cave.
> >>
> >> I completely agree with Eric.
> >>
> >> Cong we have a very serious problem with you exactly because you make
> >> quite vicious emotional statements targetted at other developers
"quite vicious" is overstatement here.
> >> merely when they say something you disagree with.
> >
> > What emotional? Pointing out Eris's words from 4 years ago is NOT
> > emotional, it is just a help.
Not really. Your "facepalm" didn't seem to be written as
humor but more as an expression of your exasperation.
> Saying "Facepalm" is emotional and has nothing to do with the
> technical issues.
Many words are emotional or conflictual.
Saying "stupid" is emotional and also has no technical content.
Stupid is used here all the time. Happily, it's generally used
as a reference to self and not about others.
However it is still occasionally and unfortunately used when
referencing proposed code or other person's behaviors.
Thankfully, these types of words are being used less and less
in discussions here.
I agree with David and Eric that it's generally better to avoid
these word choices.
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Felix Fietkau @ 2017-01-10 21:27 UTC (permalink / raw)
To: Johannes Berg, Linus Lüssing, Stephen Hemminger
Cc: netdev, bridge, linux-wireless, linux-kernel, David S . Miller,
M. Braun
In-Reply-To: <1484045763.1014.0.camel@sipsolutions.net>
On 2017-01-10 11:56, Johannes Berg wrote:
> On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
>> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
>> > I wonder if MAC80211 should be doing IGMP snooping and not bridge
>> > in this environment.
>>
>> In the long term, yes. For now, not quite sure.
>
> There's no "for now" in the kernel. Code added now will have to be
> maintained essentially forever.
I'm not sure that putting the IGMP snooping code in mac80211 is a good
idea, that would be quite a bit of code duplication.
This implementation works, it's very simple, and it's quite flexible for
a number of use cases.
Is there any remaining objection to merging this in principle (aside
from potential issues with the code)?
- Felix
^ permalink raw reply
* Re: [PATCH net-next 6/8] net: dsa: Add support for platform data
From: Andrew Lunn @ 2017-01-10 21:21 UTC (permalink / raw)
To: Florian Fainelli, John Crispin
Cc: Ingo Tuchscherer, Jason Cooper, Vivien Didelot, netdev, open list,
Russell King, Stuart Yoder, Martin Schwidefsky,
Greg Kroah-Hartman, Gregory Clement, Philippe Reynes,
David S. Miller,
moderated list:ARM/Marvell Dove/MV78xx0/Orion SOC support,
Sebastian Hesselbarth
In-Reply-To: <1530c7f6-f8ba-ab32-75aa-288549f25db9@gmail.com>
> Last time we discussed this, I had a super complex dsa2_platform_data
> that allowed you to do exactly the same thing we currently do with
> Device Tree, except that this was with platform_data. It took a lot of
> effort to get there, but I essentially had the ZII vf160 board example
> re-implemented and verified with a mockup driver (still have it in a
> branch that's not too far from net-next/master).
One thing different this time is you have associated the platform data
to an MDIO device. So the platform data represents one switch, not the
whole complex. This is going to make the platform data much simpler,
and allow the core to do the work of assembling the multiple platform
datas into one switch complex. So basically, the platform data is
dsa_chip_data.
To handle multi-CPUs, we need to move the master ethernet device and
put it next to the cpu port. So add a
struct device *netdev[DSA_MAX_PORTS];
to dsa_chip_data. It then becomes easy to represent multiple CPU
ports.
> I would very much like to see the patches and then make a decision based
> on the submission rather than project a decision on code that has not
> been submitted yet.
The first version was posted a week ago. I requested a lot of
changes. So lets see what John says about when the next version will
be ready.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 6/8] net: dsa: Add support for platform data
From: Florian Fainelli @ 2017-01-10 21:06 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Jason Cooper, Sebastian Hesselbarth, Gregory Clement,
Russell King, Vivien Didelot, David S. Miller, Philippe Reynes,
Martin Schwidefsky, Greg Kroah-Hartman, Stuart Yoder,
Ingo Tuchscherer,
moderated list:ARM/Marvell Dove/MV78xx0/Orion SOC support,
open list
In-Reply-To: <20170110204124.GL22820@lunn.ch>
On 01/10/2017 12:41 PM, Andrew Lunn wrote:
>> @@ -452,11 +455,14 @@ static int dsa_cpu_parse(struct dsa_port *port, u32 index,
>> struct net_device *ethernet_dev;
>> struct device_node *ethernet;
>>
>> - ethernet = of_parse_phandle(port->dn, "ethernet", 0);
>> - if (!ethernet)
>> - return -EINVAL;
>> + if (port->dn) {
>> + ethernet = of_parse_phandle(port->dn, "ethernet", 0);
>> + if (!ethernet)
>> + return -EINVAL;
>> + ethernet_dev = of_find_net_device_by_node(ethernet);
>> + } else
>> + ethernet_dev = dev_to_net_device(dst->pd->netdev);
Bonjour Andrew,
>
> Hi Florian
>
> This is not going to work with John's rework of my multi CPU ports
> code. I think you are going to have to modify the platform_data
> structure to support multi-CPU ports.
Last time we discussed this, I had a super complex dsa2_platform_data
that allowed you to do exactly the same thing we currently do with
Device Tree, except that this was with platform_data. It took a lot of
effort to get there, but I essentially had the ZII vf160 board example
re-implemented and verified with a mockup driver (still have it in a
branch that's not too far from net-next/master).
Your reply then AFAIR was that we should aim for something simpler and
here is the result, we end-up re-using the existing dsa_platform_data
with its limitations.
If we have legacy platforms with complex setups, I really don't think we
have those in tree, we should use dsa2_platform_data (still have the
patches somewhere for that) although I was hoping to not have to use it
since it is way more intrusive into net/dsa/dsa2.c.
All platforms that I know that will benefit from this patch series: x86
SCU from ZII (out of tree), BCM47xx, BCM63xx, Orion5x have the same
properties: single switch attached to a SPI/MDIO/MMAP with built-in
PHYs. If we have more complex setups than that, we should try to collect
the requirements.
>
> I put higher priority on cleanly integrating multi-CPU ports using
> device tree, than supporting legacy platforms. I'm O.K. with
> preparatory patches, but i think we should wait for actually platform
> data changes until after Johns code has landed and we can design the
> platform_data to work with it.
I would very much like to see the patches and then make a decision based
on the submission rather than project a decision on code that has not
been submitted yet.
Do we agree that patches 1 through 5 and 7 could go in then?
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: Implement ndo_get_phys_port_name()
From: Vivien Didelot @ 2017-01-10 20:58 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli; +Cc: netdev, davem, jiri
In-Reply-To: <20170110205043.GM22820@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> On Tue, Jan 10, 2017 at 12:32:36PM -0800, Florian Fainelli wrote:
>> Return the physical port number of a DSA created network device using
>> ndo_get_phys_port_name().
>
> At what level does this need to be unique?
The port name must be unique at the switch Linux device level.
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: Implement ndo_get_phys_port_name()
From: Florian Fainelli @ 2017-01-10 20:58 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, davem, vivien.didelot, jiri
In-Reply-To: <20170110205043.GM22820@lunn.ch>
On 01/10/2017 12:50 PM, Andrew Lunn wrote:
> On Tue, Jan 10, 2017 at 12:32:36PM -0800, Florian Fainelli wrote:
>> Return the physical port number of a DSA created network device using
>> ndo_get_phys_port_name().
>
> At what level does this need to be unique?
This needs to be unique to the switch I would say,
ndo_get_phys_switch_id would return the physical number of the switch
device in the tree/cluster, so that number plus the port name should be
an unique differentiator that is good enough for e.g: a persistent
naming rule?
>
> We can have multiple switches within one switch cluster. p->port will
> be unique within one switch, but can be repeated in a cluster.
>
> We can also have multiple clusters, and again p->port will be re-used.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: Implement ndo_get_phys_port_name()
From: Andrew Lunn @ 2017-01-10 20:50 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, davem, vivien.didelot, jiri
In-Reply-To: <20170110203237.23907-2-f.fainelli@gmail.com>
On Tue, Jan 10, 2017 at 12:32:36PM -0800, Florian Fainelli wrote:
> Return the physical port number of a DSA created network device using
> ndo_get_phys_port_name().
At what level does this need to be unique?
We can have multiple switches within one switch cluster. p->port will
be unique within one switch, but can be repeated in a cluster.
We can also have multiple clusters, and again p->port will be re-used.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/2] Revert "net: dsa: Implement ndo_get_phys_port_id"
From: Vivien Didelot @ 2017-01-10 20:44 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: davem, andrew, jiri, Florian Fainelli
In-Reply-To: <20170110203237.23907-3-f.fainelli@gmail.com>
Hi Florian,
Florian Fainelli <f.fainelli@gmail.com> writes:
> This reverts commit 3a543ef479868e36c95935de320608a7e41466ca ("net: dsa:
> Implement ndo_get_phys_port_id") since it misuses the purpose of
> ndo_get_phys_port_id(). We have ndo_get_phys_port_name() to do the
> correct thing for us now.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: Implement ndo_get_phys_port_name()
From: Vivien Didelot @ 2017-01-10 20:44 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: davem, andrew, jiri, Florian Fainelli
In-Reply-To: <20170110203237.23907-2-f.fainelli@gmail.com>
Hi Florian,
Florian Fainelli <f.fainelli@gmail.com> writes:
> Return the physical port number of a DSA created network device using
> ndo_get_phys_port_name().
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH net-next 6/8] net: dsa: Add support for platform data
From: Andrew Lunn @ 2017-01-10 20:41 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, Jason Cooper, Sebastian Hesselbarth, Gregory Clement,
Russell King, Vivien Didelot, David S. Miller, Philippe Reynes,
Martin Schwidefsky, Greg Kroah-Hartman, Stuart Yoder,
Ingo Tuchscherer,
moderated list:ARM/Marvell Dove/MV78xx0/Orion SOC support,
open list
In-Reply-To: <20170110201235.21771-7-f.fainelli@gmail.com>
> @@ -452,11 +455,14 @@ static int dsa_cpu_parse(struct dsa_port *port, u32 index,
> struct net_device *ethernet_dev;
> struct device_node *ethernet;
>
> - ethernet = of_parse_phandle(port->dn, "ethernet", 0);
> - if (!ethernet)
> - return -EINVAL;
> + if (port->dn) {
> + ethernet = of_parse_phandle(port->dn, "ethernet", 0);
> + if (!ethernet)
> + return -EINVAL;
> + ethernet_dev = of_find_net_device_by_node(ethernet);
> + } else
> + ethernet_dev = dev_to_net_device(dst->pd->netdev);
Hi Florian
This is not going to work with John's rework of my multi CPU ports
code. I think you are going to have to modify the platform_data
structure to support multi-CPU ports.
I put higher priority on cleanly integrating multi-CPU ports using
device tree, than supporting legacy platforms. I'm O.K. with
preparatory patches, but i think we should wait for actually platform
data changes until after Johns code has landed and we can design the
platform_data to work with it.
Andrew
^ permalink raw reply
* [PATCH net 10/10] net/mlx5: Only cancel recovery work when cleaning up device
From: Saeed Mahameed @ 2017-01-10 20:33 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Daniel Jurgens, Saeed Mahameed
In-Reply-To: <1484080419-24256-1-git-send-email-saeedm@mellanox.com>
From: Daniel Jurgens <danielj@mellanox.com>
Do not attempt to drain the health workqueue when unloading the device in
the recovery flow, this can cause a deadlock when the recovery work
tries to cancel itself with sync.
Because the work is no longer unconditionally canceled when unloading, it
must be explicitly canceled in the AER flow.
fixes: 689a248df83b ("net/mlx5: Cancel recovery work in remove flow")
Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 6547f22..d01e9f2 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -1195,7 +1195,8 @@ static int mlx5_unload_one(struct mlx5_core_dev *dev, struct mlx5_priv *priv,
{
int err = 0;
- mlx5_drain_health_wq(dev);
+ if (cleanup)
+ mlx5_drain_health_wq(dev);
mutex_lock(&dev->intf_state_mutex);
if (test_bit(MLX5_INTERFACE_STATE_DOWN, &dev->intf_state)) {
@@ -1359,9 +1360,10 @@ static pci_ers_result_t mlx5_pci_err_detected(struct pci_dev *pdev,
mlx5_enter_error_state(dev);
mlx5_unload_one(dev, priv, false);
- /* In case of kernel call save the pci state */
+ /* In case of kernel call save the pci state and drain the health wq */
if (state) {
pci_save_state(pdev);
+ mlx5_drain_health_wq(dev);
mlx5_pci_disable_device(dev);
}
--
2.7.4
^ permalink raw reply related
* [PATCH net 09/10] net/mlx5e: Remove WARN_ONCE from adaptive moderation code
From: Saeed Mahameed @ 2017-01-10 20:33 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Gil Rockah, Saeed Mahameed
In-Reply-To: <1484080419-24256-1-git-send-email-saeedm@mellanox.com>
From: Gil Rockah <gilr@mellanox.com>
When trying to do interface down or changing interface configuration
under heavy traffic, some of the adaptive moderation corner cases can
occur and leave a WARN_ONCE call trace in the kernel log.
Those WARN_ONCE are meant for debug only, and should have been inserted
only under debug. We avoid such call traces by removing those WARN_ONCE.
Fixes: cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing")
Signed-off-by: Gil Rockah <gilr@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c
index 1fffe48..cbfac06 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c
@@ -109,7 +109,6 @@ static bool mlx5e_am_on_top(struct mlx5e_rx_am *am)
switch (am->tune_state) {
case MLX5E_AM_PARKING_ON_TOP:
case MLX5E_AM_PARKING_TIRED:
- WARN_ONCE(true, "mlx5e_am_on_top: PARKING\n");
return true;
case MLX5E_AM_GOING_RIGHT:
return (am->steps_left > 1) && (am->steps_right == 1);
@@ -123,7 +122,6 @@ static void mlx5e_am_turn(struct mlx5e_rx_am *am)
switch (am->tune_state) {
case MLX5E_AM_PARKING_ON_TOP:
case MLX5E_AM_PARKING_TIRED:
- WARN_ONCE(true, "mlx5e_am_turn: PARKING\n");
break;
case MLX5E_AM_GOING_RIGHT:
am->tune_state = MLX5E_AM_GOING_LEFT;
@@ -144,7 +142,6 @@ static int mlx5e_am_step(struct mlx5e_rx_am *am)
switch (am->tune_state) {
case MLX5E_AM_PARKING_ON_TOP:
case MLX5E_AM_PARKING_TIRED:
- WARN_ONCE(true, "mlx5e_am_step: PARKING\n");
break;
case MLX5E_AM_GOING_RIGHT:
if (am->profile_ix == (MLX5E_PARAMS_AM_NUM_PROFILES - 1))
@@ -282,10 +279,8 @@ static void mlx5e_am_calc_stats(struct mlx5e_rx_am_sample *start,
u32 delta_us = ktime_us_delta(end->time, start->time);
unsigned int npkts = end->pkt_ctr - start->pkt_ctr;
- if (!delta_us) {
- WARN_ONCE(true, "mlx5e_am_calc_stats: delta_us=0\n");
+ if (!delta_us)
return;
- }
curr_stats->ppms = (npkts * USEC_PER_MSEC) / delta_us;
curr_stats->epms = (MLX5E_AM_NEVENTS * USEC_PER_MSEC) / delta_us;
--
2.7.4
^ permalink raw reply related
* [PATCH net 01/10] net/mlx5e: Properly handle offloading of source udp port for IP tunnels
From: Saeed Mahameed @ 2017-01-10 20:33 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Saeed Mahameed
In-Reply-To: <1484080419-24256-1-git-send-email-saeedm@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
We can offload the matching on source udp port of ip tunnels for
decapsulation. We can not offload setting source udp port for tunnels
as part of encapsulation. Fix both the code that deals with matching
offload (decap) and the code that deal with encap offload to align with
that.
Fixes: a54e20b4fcae ('net/mlx5e: Add basic TC tunnel set action for SRIOV offloads')
Fixes: bbd00f7e2349 ('net/mlx5e: Add TC tunnel release action for SRIOV offloads')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index f8829b5..b60fece 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -239,10 +239,6 @@ static int parse_tunnel_attr(struct mlx5e_priv *priv,
if (memchr_inv(&mask->dst, 0xff, sizeof(mask->dst)))
return -EOPNOTSUPP;
- /* udp src port isn't supported */
- if (memchr_inv(&mask->src, 0, sizeof(mask->src)))
- return -EOPNOTSUPP;
-
if (mlx5e_vxlan_lookup_port(priv, be16_to_cpu(key->dst)) &&
MLX5_CAP_ESW(priv->mdev, vxlan_encap_decap))
parse_vxlan_attr(spec, f);
@@ -254,6 +250,10 @@ static int parse_tunnel_attr(struct mlx5e_priv *priv,
MLX5_SET(fte_match_set_lyr_2_4, headers_v,
udp_dport, ntohs(key->dst));
+ MLX5_SET(fte_match_set_lyr_2_4, headers_c,
+ udp_sport, ntohs(mask->src));
+ MLX5_SET(fte_match_set_lyr_2_4, headers_v,
+ udp_sport, ntohs(key->src));
} else { /* udp dst port must be given */
return -EOPNOTSUPP;
}
@@ -796,6 +796,10 @@ static int mlx5e_attach_encap(struct mlx5e_priv *priv,
if (!memchr_inv(&key->tp_dst, 0, sizeof(key->tp_dst)))
return -EOPNOTSUPP;
+ /* setting udp src port isn't supported */
+ if (memchr_inv(&key->tp_src, 0, sizeof(key->tp_src)))
+ return -EOPNOTSUPP;
+
if (mlx5e_vxlan_lookup_port(priv, be16_to_cpu(key->tp_dst)) &&
MLX5_CAP_ESW(priv->mdev, vxlan_encap_decap)) {
info.tp_dst = key->tp_dst;
--
2.7.4
^ permalink raw reply related
* [PATCH net 06/10] net/mlx5e: Fix kbuild warnings for uninitialized parameters
From: Saeed Mahameed @ 2017-01-10 20:33 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Hadar Hen Zion, Saeed Mahameed
In-Reply-To: <1484080419-24256-1-git-send-email-saeedm@mellanox.com>
From: Hadar Hen Zion <hadarh@mellanox.com>
kbuild warn about parameters that may be used uninitialized, fix it.
Fixes: a54e20b4fcae ('net/mlx5e: Add basic TC tunnel set action for SRIOV offloads')
Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index a35fa1e..5dbc81d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -737,8 +737,8 @@ static int mlx5e_create_encap_header_ipv4(struct mlx5e_priv *priv,
struct flowi4 fl4 = {};
char *encap_header;
int encap_size;
- __be32 saddr;
- int ttl;
+ __be32 saddr = 0;
+ int ttl = 0;
int err;
encap_header = kzalloc(max_encap_size, GFP_KERNEL);
--
2.7.4
^ permalink raw reply related
* [PATCH net 08/10] net/mlx5e: Un-register uplink representor on nic_disable
From: Saeed Mahameed @ 2017-01-10 20:33 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Saeed Mahameed
In-Reply-To: <1484080419-24256-1-git-send-email-saeedm@mellanox.com>
The code before this patch registered uplink e-Switch representor
on nic_enable and unregistered on nic_cleanup, the right place
for this unregister is in nic_disable.
Fixes: 127ea380acc9 ("net/mlx5: Add Representors registration API")
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reviewed-by: Mohamad Haj Yahia <mohamad@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 1236b27..2b7dd31 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3675,14 +3675,8 @@ static void mlx5e_nic_init(struct mlx5_core_dev *mdev,
static void mlx5e_nic_cleanup(struct mlx5e_priv *priv)
{
- struct mlx5_core_dev *mdev = priv->mdev;
- struct mlx5_eswitch *esw = mdev->priv.eswitch;
-
mlx5e_vxlan_cleanup(priv);
- if (MLX5_CAP_GEN(mdev, vport_group_manager))
- mlx5_eswitch_unregister_vport_rep(esw, 0);
-
if (priv->xdp_prog)
bpf_prog_put(priv->xdp_prog);
}
@@ -3807,9 +3801,14 @@ static void mlx5e_nic_enable(struct mlx5e_priv *priv)
static void mlx5e_nic_disable(struct mlx5e_priv *priv)
{
+ struct mlx5_core_dev *mdev = priv->mdev;
+ struct mlx5_eswitch *esw = mdev->priv.eswitch;
+
queue_work(priv->wq, &priv->set_rx_mode_work);
+ if (MLX5_CAP_GEN(mdev, vport_group_manager))
+ mlx5_eswitch_unregister_vport_rep(esw, 0);
mlx5e_disable_async_events(priv);
- mlx5_lag_remove(priv->mdev);
+ mlx5_lag_remove(mdev);
}
static const struct mlx5e_profile mlx5e_nic_profile = {
--
2.7.4
^ permalink raw reply related
* [PATCH net 02/10] net/mlx5e: Warn when rejecting offload attempts of IP tunnels
From: Saeed Mahameed @ 2017-01-10 20:33 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Saeed Mahameed
In-Reply-To: <1484080419-24256-1-git-send-email-saeedm@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
We silently reject offloading of IPv6 tunnels, non vxlan tunnels,
vxlan tunnels where the dst port to match is not provided, etc.
Be a bit more verbose and print a warning so the user better
realizes what went wrong here and can fix it.
Fixes: a54e20b4fcae ('net/mlx5e: Add basic TC tunnel set action for SRIOV offloads')
Fixes: bbd00f7e2349 ('net/mlx5e: Add TC tunnel release action for SRIOV offloads')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 30 ++++++++++++++++++++-----
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index b60fece..d2fc055 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -237,13 +237,16 @@ static int parse_tunnel_attr(struct mlx5e_priv *priv,
/* Full udp dst port must be given */
if (memchr_inv(&mask->dst, 0xff, sizeof(mask->dst)))
- return -EOPNOTSUPP;
+ goto vxlan_match_offload_err;
if (mlx5e_vxlan_lookup_port(priv, be16_to_cpu(key->dst)) &&
MLX5_CAP_ESW(priv->mdev, vxlan_encap_decap))
parse_vxlan_attr(spec, f);
- else
+ else {
+ netdev_warn(priv->netdev,
+ "%d isn't an offloaded vxlan udp dport\n", be16_to_cpu(key->dst));
return -EOPNOTSUPP;
+ }
MLX5_SET(fte_match_set_lyr_2_4, headers_c,
udp_dport, ntohs(mask->dst));
@@ -255,7 +258,10 @@ static int parse_tunnel_attr(struct mlx5e_priv *priv,
MLX5_SET(fte_match_set_lyr_2_4, headers_v,
udp_sport, ntohs(key->src));
} else { /* udp dst port must be given */
- return -EOPNOTSUPP;
+vxlan_match_offload_err:
+ netdev_warn(priv->netdev,
+ "IP tunnel decap offload supported only for vxlan, must set UDP dport\n");
+ return -EOPNOTSUPP;
}
if (dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS)) {
@@ -346,6 +352,9 @@ static int __parse_cls_flower(struct mlx5e_priv *priv,
if (parse_tunnel_attr(priv, spec, f))
return -EOPNOTSUPP;
break;
+ case FLOW_DISSECTOR_KEY_IPV6_ADDRS:
+ netdev_warn(priv->netdev,
+ "IPv6 tunnel decap offload isn't supported\n");
default:
return -EOPNOTSUPP;
}
@@ -792,13 +801,17 @@ static int mlx5e_attach_encap(struct mlx5e_priv *priv,
int tunnel_type;
int err;
- /* udp dst port must be given */
+ /* udp dst port must be set */
if (!memchr_inv(&key->tp_dst, 0, sizeof(key->tp_dst)))
- return -EOPNOTSUPP;
+ goto vxlan_encap_offload_err;
/* setting udp src port isn't supported */
- if (memchr_inv(&key->tp_src, 0, sizeof(key->tp_src)))
+ if (memchr_inv(&key->tp_src, 0, sizeof(key->tp_src))) {
+vxlan_encap_offload_err:
+ netdev_warn(priv->netdev,
+ "must set udp dst port and not set udp src port\n");
return -EOPNOTSUPP;
+ }
if (mlx5e_vxlan_lookup_port(priv, be16_to_cpu(key->tp_dst)) &&
MLX5_CAP_ESW(priv->mdev, vxlan_encap_decap)) {
@@ -806,6 +819,8 @@ static int mlx5e_attach_encap(struct mlx5e_priv *priv,
info.tun_id = tunnel_id_to_key32(key->tun_id);
tunnel_type = MLX5_HEADER_TYPE_VXLAN;
} else {
+ netdev_warn(priv->netdev,
+ "%d isn't an offloaded vxlan udp dport\n", be16_to_cpu(key->tp_dst));
return -EOPNOTSUPP;
}
@@ -813,6 +828,9 @@ static int mlx5e_attach_encap(struct mlx5e_priv *priv,
case AF_INET:
info.daddr = key->u.ipv4.dst;
break;
+ case AF_INET6:
+ netdev_warn(priv->netdev,
+ "IPv6 tunnel encap offload isn't supported\n");
default:
return -EOPNOTSUPP;
}
--
2.7.4
^ permalink raw reply related
* [PATCH net 04/10] net/mlx5e: Properly get address type of encapsulation IP headers
From: Saeed Mahameed @ 2017-01-10 20:33 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Saeed Mahameed
In-Reply-To: <1484080419-24256-1-git-send-email-saeedm@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
As done elsewhere in our TC/flower offload code, the address type of
the encapsulation IP headers should be realized accroding to the
addr_type field of the encapsulation control dissector key, do that.
Fixes: bbd00f7e2349 ('net/mlx5e: Add TC tunnel release action for SRIOV offloads')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index b62f06f..9cfddd9 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -225,6 +225,11 @@ static int parse_tunnel_attr(struct mlx5e_priv *priv,
void *headers_v = MLX5_ADDR_OF(fte_match_param, spec->match_value,
outer_headers);
+ struct flow_dissector_key_control *enc_control =
+ skb_flow_dissector_target(f->dissector,
+ FLOW_DISSECTOR_KEY_ENC_CONTROL,
+ f->key);
+
if (dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_PORTS)) {
struct flow_dissector_key_ports *key =
skb_flow_dissector_target(f->dissector,
@@ -264,7 +269,7 @@ static int parse_tunnel_attr(struct mlx5e_priv *priv,
return -EOPNOTSUPP;
}
- if (dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS)) {
+ if (enc_control->addr_type == FLOW_DISSECTOR_KEY_IPV4_ADDRS) {
struct flow_dissector_key_ipv4_addrs *key =
skb_flow_dissector_target(f->dissector,
FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS,
@@ -286,10 +291,10 @@ static int parse_tunnel_attr(struct mlx5e_priv *priv,
MLX5_SET(fte_match_set_lyr_2_4, headers_v,
dst_ipv4_dst_ipv6.ipv4_layout.ipv4,
ntohl(key->dst));
- }
- MLX5_SET_TO_ONES(fte_match_set_lyr_2_4, headers_c, ethertype);
- MLX5_SET(fte_match_set_lyr_2_4, headers_v, ethertype, ETH_P_IP);
+ MLX5_SET_TO_ONES(fte_match_set_lyr_2_4, headers_c, ethertype);
+ MLX5_SET(fte_match_set_lyr_2_4, headers_v, ethertype, ETH_P_IP);
+ }
/* Enforce DMAC when offloading incoming tunneled flows.
* Flow counters require a match on the DMAC.
--
2.7.4
^ permalink raw reply related
* [PATCH net 03/10] net/mlx5e: TC ipv4 tunnel encap offload error flow fixes
From: Saeed Mahameed @ 2017-01-10 20:33 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Saeed Mahameed
In-Reply-To: <1484080419-24256-1-git-send-email-saeedm@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
When the route lookup fails we should return the actual error.
When the neigh isn't valid, we should return -EOPNOTSUPP as done
in similar cases along the code.
When the offload can't take place as of invalid neigh etc, we
must release the neigh.
Fixes: a54e20b4fcae ('net/mlx5e: Add basic TC tunnel set action for SRIOV offloads')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index d2fc055..b62f06f 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -656,17 +656,14 @@ static int mlx5e_route_lookup_ipv4(struct mlx5e_priv *priv,
#if IS_ENABLED(CONFIG_INET)
rt = ip_route_output_key(dev_net(mirred_dev), fl4);
- if (IS_ERR(rt)) {
- pr_warn("%s: no route to %pI4\n", __func__, &fl4->daddr);
- return -EOPNOTSUPP;
- }
+ if (IS_ERR(rt))
+ return PTR_ERR(rt);
#else
return -EOPNOTSUPP;
#endif
if (!switchdev_port_same_parent_id(priv->netdev, rt->dst.dev)) {
- pr_warn("%s: Can't offload the flow, netdevices aren't on the same HW e-switch\n",
- __func__);
+ pr_warn("%s: can't offload, devices not on same HW e-switch\n", __func__);
ip_rt_put(rt);
return -EOPNOTSUPP;
}
@@ -727,8 +724,8 @@ static int mlx5e_create_encap_header_ipv4(struct mlx5e_priv *priv,
struct net_device **out_dev)
{
int max_encap_size = MLX5_CAP_ESW(priv->mdev, max_encap_header_size);
+ struct neighbour *n = NULL;
struct flowi4 fl4 = {};
- struct neighbour *n;
char *encap_header;
int encap_size;
__be32 saddr;
@@ -759,7 +756,8 @@ static int mlx5e_create_encap_header_ipv4(struct mlx5e_priv *priv,
e->out_dev = *out_dev;
if (!(n->nud_state & NUD_VALID)) {
- err = -ENOTSUPP;
+ pr_warn("%s: can't offload, neighbour to %pI4 invalid\n", __func__, &fl4.daddr);
+ err = -EOPNOTSUPP;
goto out;
}
@@ -781,6 +779,8 @@ static int mlx5e_create_encap_header_ipv4(struct mlx5e_priv *priv,
err = mlx5_encap_alloc(priv->mdev, e->tunnel_type,
encap_size, encap_header, &e->encap_id);
out:
+ if (err && n)
+ neigh_release(n);
kfree(encap_header);
return err;
}
--
2.7.4
^ permalink raw reply related
* [PATCH net 07/10] net/mlx5e: Properly handle FW errors while adding TC rules
From: Saeed Mahameed @ 2017-01-10 20:33 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Saeed Mahameed
In-Reply-To: <1484080419-24256-1-git-send-email-saeedm@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
When the firmware returns an error (common example is an attempt to
add twice the same rule which is refused by the some FWs), we are not
properly derefing/cleaning few resources allocated on the way.
Examples are vport vlan deref under eswitch vlan offloads, and encap
entry/neighbour deref under eswitch encapsulation offloads, fix that.
Fixes: a54e20b4fcae ('net/mlx5e: Add basic TC tunnel set action for SRIOV offloads')
Fixes: 8b32580df1cb ('net/mlx5e: Add TC vlan action for SRIOV offloads')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 5dbc81d..118cea5 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -161,15 +161,21 @@ static void mlx5e_detach_encap(struct mlx5e_priv *priv,
}
}
+/* we get here also when setting rule to the FW failed, etc. It means that the
+ * flow rule itself might not exist, but some offloading related to the actions
+ * should be cleaned.
+ */
static void mlx5e_tc_del_flow(struct mlx5e_priv *priv,
struct mlx5e_tc_flow *flow)
{
struct mlx5_eswitch *esw = priv->mdev->priv.eswitch;
struct mlx5_fc *counter = NULL;
- counter = mlx5_flow_rule_counter(flow->rule);
-
- mlx5_del_flow_rules(flow->rule);
+ if (!IS_ERR(flow->rule)) {
+ counter = mlx5_flow_rule_counter(flow->rule);
+ mlx5_del_flow_rules(flow->rule);
+ mlx5_fc_destroy(priv->mdev, counter);
+ }
if (esw && esw->mode == SRIOV_OFFLOADS) {
mlx5_eswitch_del_vlan_action(esw, flow->attr);
@@ -177,8 +183,6 @@ static void mlx5e_tc_del_flow(struct mlx5e_priv *priv,
mlx5e_detach_encap(priv, flow);
}
- mlx5_fc_destroy(priv->mdev, counter);
-
if (!mlx5e_tc_num_filters(priv) && (priv->fs.tc.t)) {
mlx5_destroy_flow_table(priv->fs.tc.t);
priv->fs.tc.t = NULL;
@@ -1017,7 +1021,7 @@ int mlx5e_configure_flower(struct mlx5e_priv *priv, __be16 protocol,
if (IS_ERR(flow->rule)) {
err = PTR_ERR(flow->rule);
- goto err_free;
+ goto err_del_rule;
}
err = rhashtable_insert_fast(&tc->ht, &flow->node,
@@ -1028,7 +1032,7 @@ int mlx5e_configure_flower(struct mlx5e_priv *priv, __be16 protocol,
goto out;
err_del_rule:
- mlx5_del_flow_rules(flow->rule);
+ mlx5e_tc_del_flow(priv, flow);
err_free:
kfree(flow);
--
2.7.4
^ permalink raw reply related
* [PATCH net 00/10] Mellanox mlx5 fixes and cleanups 2017-01-10
From: Saeed Mahameed @ 2017-01-10 20:33 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Saeed Mahameed
Hi Dave,
This series includes some mlx5e general cleanups from Daniel, Gil, Hadar
and myself.
Also it includes some critical mlx5e TC offloads fixes from Or Gerlitz.
For -stable:
- net/mlx5e: Remove WARN_ONCE from adaptive moderation code
Although this fix doesn't affect any functionality, I thought it is
better to clean this -WARN_ONCE- up for -stable in case someone hits
such corner case.
Please apply and let me know if there's any problem.
Thanks,
Saeed.
Daniel Jurgens (1):
net/mlx5: Only cancel recovery work when cleaning up device
Gil Rockah (1):
net/mlx5e: Remove WARN_ONCE from adaptive moderation code
Hadar Hen Zion (1):
net/mlx5e: Fix kbuild warnings for uninitialized parameters
Or Gerlitz (6):
net/mlx5e: Properly handle offloading of source udp port for IP
tunnels
net/mlx5e: Warn when rejecting offload attempts of IP tunnels
net/mlx5e: TC ipv4 tunnel encap offload error flow fixes
net/mlx5e: Properly get address type of encapsulation IP headers
net/mlx5e: Set inline mode requirements for matching on IP fragments
net/mlx5e: Properly handle FW errors while adding TC rules
Saeed Mahameed (1):
net/mlx5e: Un-register uplink representor on nic_disable
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 13 ++-
drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c | 7 +-
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 93 +++++++++++++++-------
drivers/net/ethernet/mellanox/mlx5/core/main.c | 6 +-
4 files changed, 75 insertions(+), 44 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH net 05/10] net/mlx5e: Set inline mode requirements for matching on IP fragments
From: Saeed Mahameed @ 2017-01-10 20:33 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Saeed Mahameed
In-Reply-To: <1484080419-24256-1-git-send-email-saeedm@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
For e-switch level matching on packets being an IP fragment, we
need to make sure the source vport inline mode is L3, fix that.
Fixes: 3f7d0eb42d59 ('net/mlx5e: Offload TC matching on packets being IP fragments')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 9cfddd9..a35fa1e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -389,6 +389,10 @@ static int __parse_cls_flower(struct mlx5e_priv *priv,
MLX5_SET(fte_match_set_lyr_2_4, headers_c, frag, 1);
MLX5_SET(fte_match_set_lyr_2_4, headers_v, frag,
key->flags & FLOW_DIS_IS_FRAGMENT);
+
+ /* the HW doesn't need L3 inline to match on frag=no */
+ if (key->flags & FLOW_DIS_IS_FRAGMENT)
+ *min_inline = MLX5_INLINE_MODE_IP;
}
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/2] Revert "net: dsa: Implement ndo_get_phys_port_id"
From: Florian Fainelli @ 2017-01-10 20:32 UTC (permalink / raw)
To: netdev; +Cc: davem, vivien.didelot, andrew, jiri, Florian Fainelli
In-Reply-To: <20170110203237.23907-1-f.fainelli@gmail.com>
This reverts commit 3a543ef479868e36c95935de320608a7e41466ca ("net: dsa:
Implement ndo_get_phys_port_id") since it misuses the purpose of
ndo_get_phys_port_id(). We have ndo_get_phys_port_name() to do the
correct thing for us now.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
net/dsa/slave.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index fed3fbd403cb..0cdcaf526987 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -983,15 +983,6 @@ static void dsa_slave_poll_controller(struct net_device *dev)
}
#endif
-static int dsa_slave_get_phys_port_id(struct net_device *dev,
- struct netdev_phys_item_id *ppid)
-{
- struct dsa_slave_priv *p = netdev_priv(dev);
-
- ppid->id_len = sizeof(p->port);
- memcpy(ppid->id, &p->port, ppid->id_len);
-}
-
static int dsa_slave_get_phys_port_name(struct net_device *dev,
char *name, size_t len)
{
@@ -1050,7 +1041,6 @@ static const struct net_device_ops dsa_slave_netdev_ops = {
.ndo_bridge_getlink = switchdev_port_bridge_getlink,
.ndo_bridge_setlink = switchdev_port_bridge_setlink,
.ndo_bridge_dellink = switchdev_port_bridge_dellink,
- .ndo_get_phys_port_id = dsa_slave_get_phys_port_id,
.ndo_get_phys_port_name = dsa_slave_get_phys_port_name,
};
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox