[PATCH RFC net] net/sched: cls_flower: Reject duplicated rules also under skip_sw

Currently, duplicated rules are rejected only for skip_hw or "none", hence allowing users to push duplicated into HW for no reason. Use the flower tables to protect for that. Signed-off-by: Or Gerlitz Signed-off-by: Paul Blakey Reported-by: Chris Mi --- net/sched/cls_flo

[PATCH net-next V2 0/2] net/sched: act_tunnel_key: support key-less tunnels

This short series from Adi Nissim allows to support key-less tunnels by the tc tunnel key actions, which is needed for some GRE use-cases. changes from V0: - addresses build warning spotted by kbuild, make sure to always init to zero the tunnel key Adi Nissim (2): net/sched:

[PATCH net-next V2 2/2] net/sched: act_tunnel_key: Don't dump dst port if it wasn't set

From: Adi Nissim It's possible to set a tunnel without a destination port. However, on dump(), a zero dst port is returned to user space even if it was not set, fix that. Note that so far it wasn't required, b/c key less tunnels were not supported and the UDP tunnels do require destination

[PATCH net-next V2 1/2] net/sched: act_tunnel_key: Allow key-less tunnels

From: Adi Nissim Allow setting a tunnel without a tunnel key. This is required for tunneling protocols, such as GRE, that define the key as an optional field. Signed-off-by: Adi Nissim Acked-by: Or Gerlitz Reviewed-by: Oz Shlomo Acked-by: Jiri Pirko --- net/sched/act_tunnel_key.c | 21

[PATCH net-next 2/2] net/sched: act_tunnel_key: Don't dump dst port if it wasn't set

From: Adi Nissim It's possible to set a tunnel without a destination port. However, on dump(), a zero dst port is returned to user space even if it was not set, fix that. Note that so far it wasn't required, b/c key less tunnels were not supported and the UDP tunnels do require destination

[PATCH net-next 0/2] net/sched: act_tunnel_key: support key-less tunnels

This short series from Adi Nissim allows to support key-less tunnels by the tc tunnel key actions, which is needed for some GRE use-cases. Adi Nissim (2): net/sched: act_tunnel_key: Allow key-less tunnels net/sched: act_tunnel_key: Don't dump dst port if it wasn't set

[PATCH net-next 1/2] net/sched: act_tunnel_key: Allow key-less tunnels

From: Adi Nissim Allow setting a tunnel without a tunnel key. This is required for tunneling protocols, such as GRE, that define the key as an optional field. Signed-off-by: Adi Nissim Acked-by: Or Gerlitz Reviewed-by: Oz Shlomo Acked-by: Jiri Pirko --- net/sched/act_tunnel_key.c | 19

Re: [PATCH 00/12 net-next,v2] add flow_rule infrastructure

On Mon, Nov 19, 2018 at 10:14 PM David Miller wrote: > From: Pablo Neira Ayuso > Date: Mon, 19 Nov 2018 01:15:07 +0100 > > > This patchset introduces a kernel intermediate representation (IR) to > > express ACL hardware offloads, as already described in previous RFC and > > v1 patchset [1] [2].

Re: [PATCH 00/10] add flow_rule infrastructure

On Fri, Nov 16, 2018 at 3:43 AM Pablo Neira Ayuso wrote: > This patchset introduces a kernel intermediate representation (IR) to > express ACL hardware offloads, this is heavily based on the existing > flow dissector infrastructure and the TC actions. This IR can be used by > different frontend

Re: [PATCH net-next 0/6] net: sched: indirect tc block cb registration

On Mon, Nov 12, 2018 at 6:13 AM Jakub Kicinski wrote: > On Sun, 11 Nov 2018 09:55:35 -0800 (PST), David Miller wrote: > > From: Jakub Kicinski > > Date: Fri, 9 Nov 2018 21:21:25 -0800 > > > > > John says: > > > > > > This patchset introduces an alternative to egdev offload by allowing a > > >

Re: [RFC net-next v2 1/8] net: sched: register callbacks for indirect tc block binds

On Mon, Oct 29, 2018 at 2:54 PM John Hurley wrote: > On Sun, Oct 28, 2018 at 11:10 AM Or Gerlitz wrote: > > > > On Thu, Oct 25, 2018 at 3:28 PM John Hurley > > wrote: > > > Currently drivers can register to receive TC block bind/unbind callbacks > > >

Re: [RFC net-next v2 1/8] net: sched: register callbacks for indirect tc block binds

On Thu, Oct 25, 2018 at 3:28 PM John Hurley wrote: > Currently drivers can register to receive TC block bind/unbind callbacks > by implementing the setup_tc ndo in any of their given netdevs. However, > drivers may also be interested in binds to higher level devices (e.g. > tunnel drivers) to

Re: [PATCH] net/mlx5: Allocate enough space for the FDB sub-namespaces

On Sun, Oct 21, 2018 at 2:47 PM Or Gerlitz wrote: > > From: Dan Carpenter > > FDB_MAX_CHAIN is three. We wanted to allocate enough memory to hold four > structs but there are missing parentheses so we only allocate enough > memory for three structs and the first byte

Re: [PATCH] net/mlx5: allocate enough space in

On Mon, Oct 22, 2018 at 8:23 AM Dan Carpenter wrote: > > On Sun, Oct 21, 2018 at 01:56:26PM +0300, Or Gerlitz wrote: > > I will re-post your patch, this time to netdev since the original > > commit is there > > and so should be the fix, thanks for reporting/fixing! >

[PATCH] net/mlx5: Allocate enough space for the FDB sub-namespaces

tiple namespaces") Signed-off-by: Dan Carpenter Reviewed-by: Or Gerlitz --- drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_co

Re: [PATCH] net/mlx5: allocate enough space in

On Sat, Oct 20, 2018 at 11:37 PM Or Gerlitz wrote: > On Fri, Oct 19, 2018 at 11:08 PM Dan Carpenter > wrote: > > FDB_MAX_CHAIN is 3. We wanted to allocate enough memory to hold four > > structs but there are missing parentheses so we only allocate enough > >

Re: [PATCH] net/mlx5: allocate enough space in

On Fri, Oct 19, 2018 at 11:08 PM Dan Carpenter wrote: > > FDB_MAX_CHAIN is 3. We wanted to allocate enough memory to hold four > structs but there are missing parentheses so we only allocate enough > memory for three structs and the first byte of the fourth one. yeah, seems that we were wrong

Re: [PATCH net-next 0/3] nfp: flower: speed up stats update loop

On Tue, Oct 9, 2018 at 4:58 AM Jakub Kicinski wrote: > Given that our statistic IDs are already array indices, and considering > each statistic is only 24B in size, we decided to forego the use 8B packet + 8B bytes --> 16B -- does your FW/HW provide last use? how do you express this lastuse

Re: [RFC 0/2] net: sched: indirect/remote setup tc block cb registering

On Thu, Oct 4, 2018 at 8:19 PM Jakub Kicinski wrote: > On Thu, 4 Oct 2018 17:20:43 +0100, John Hurley wrote: > > > > In this case the hw driver will receive the rules from the tunnel > > > > device directly. > > > > The driver can then offload them as it sees fit. > > > > > > if both instances

Re: re iproute2 - don't return error on success fix

On Mon, Oct 8, 2018 at 3:41 PM Phil Sutter wrote: > > $ ./tc/tc filter add dev enp33s0f0 protocol ip parent : flower > > skip_sw ip_flags firstfrag action drop && echo "success" || echo > > "failed" > > RTNETLINK answers: Operation not supported > > success > > Interestingly, your output

Re: [RFC 0/2] net: sched: indirect/remote setup tc block cb registering

On Thu, Oct 4, 2018 at 6:44 PM John Hurley wrote: > On Thu, Oct 4, 2018 at 3:28 PM Or Gerlitz wrote: > > On Thu, Oct 4, 2018 at 7:55 AM Jakub Kicinski > > wrote: > > > This patchset introduces as an alternative to egdev offload by allowing a > > > driver t

Re: [RFC 0/2] net: sched: indirect/remote setup tc block cb registering

On Thu, Oct 4, 2018 at 7:55 AM Jakub Kicinski wrote: > > Hi! > > This set contains a rough RFC implementation of a proposed [1] replacement > for egdev cls_flower offloads. I did some last minute restructuring > and removal of parts I felt were unnecessary, so if there are glaring bugs > they

Re: [net-next 08/15] ice: Notify VF of link status change

On Wed, Oct 3, 2018 at 6:46 PM Jeff Kirsher wrote: > From: Anirudh Venkataramanan > > When PF gets a link status change event, notify the VFs of the same. so you always want to block east/west traffic when the uplink is down? why? The correct approach is to have vf/vport e-switch representor

Re: re iproute2 - don't return error on success fix

On Thu, Sep 27, 2018 at 3:53 PM Phil Sutter wrote: > On Thu, Sep 27, 2018 at 03:22:41PM +0300, Or Gerlitz wrote: > > Something is still broken also after commit b45e300 "libnetlink: don't > > return error on success" - when error is returned, the error code is > >

Re: [PATCH v3 net-next 4/9] bnxt_en: Use ignore_ari devlink parameter

On Fri, Sep 28, 2018 at 9:30 AM Vasundhara Volam wrote: > This patch adds support for ignore_ari generic permanent mode > devlink parameter. This parameter is disabled by default. It can be > enabled using devlink param commands. > > ignore_ari - If enabled, device ignores ARI(Alternate Routing

Re: re iproute2 - don't return error on success fix

On Thu, Sep 27, 2018 at 3:53 PM Phil Sutter wrote: > Hmm, I can't reproduce this. My HEAD is at the commit you mentioned: > > | % sudo ./tc/tc filter add dev d0 protocol ip parent : flower skip_sw > ip_flags nofirstfrag action drop > | RTNETLINK answers: Operation not supported > | We have

re iproute2 - don't return error on success fix

Something is still broken also after commit b45e300 "libnetlink: don't return error on success" - when error is returned, the error code is success.. $ tc filter add dev enp33s0f0 protocol ip parent : flower skip_sw ip_flags nofirstfrag action drop && echo "success" || echo "failed"

Re: [RFC PATCH net-next v1 00/14] rename and shrink i40evf

On Fri, Sep 14, 2018 at 10:17 PM, Jesse Brandeburg wrote: > On Fri, 14 Sep 2018 12:10:45 +0300 Or wrote: >> On Fri, Sep 14, 2018 at 1:31 AM, Jesse Brandeburg >> wrote: >> on what HW ring format do you standardize? do i40e/Fortville and >> ice/what's-the-intel-code-name? HWs can/use the same

Re: [PATCH rdma-next v1 0/7] Preparation to DevX extension series

On Thu, Sep 20, 2018 at 9:35 PM, Leon Romanovsky wrote: > From: Leon Romanovsky > Set uid as part of various IB commands so that the firmware can manage > the IB object in a secured way. This series deals with FS core and commands used by the Ethernet driver > net/mlx5: Update mlx5_ifc with

Re: [PATCH mlx5-next v1 7/7] net/mlx5: Update mlx5_ifc with DEVX UID bits

On Thu, Sep 20, 2018 at 9:35 PM, Leon Romanovsky wrote: > Add DEVX information to WQ, SRQ, CQ, TRI, TIS, QP, > RQ, XRCD, PD, MKEY and MCG. typo - TRI --> TIR "DEVX information" is a bit cryptic - what does xxx_valid means for the devx use case (fw command is issued by devx process) - and what

Re: [PATCH mlx5-next v1 7/7] net/mlx5: Update mlx5_ifc with DEVX UID bits

On Thu, Sep 20, 2018 at 9:35 PM, Leon Romanovsky wrote: > From: Leon Romanovsky > > Add DEVX information to WQ, SRQ, CQ, TRI, TIS, QP, > RQ, XRCD, PD, MKEY and MCG. > > Signed-off-by: Leon Romanovsky > --- > include/linux/mlx5/mlx5_ifc.h | 67 > +++ > 1

Re: [PATCH rdma-next 00/24] Extend DEVX functionality

On Mon, Sep 17, 2018 at 11:07 PM, Leon Romanovsky wrote: > On Mon, Sep 17, 2018 at 10:51:29PM +0300, Or Gerlitz wrote: >> On Mon, Sep 17, 2018 at 10:34 PM, Leon Romanovsky >> wrote: >> > On Mon, Sep 17, 2018 at 02:03:53PM +0300, Leon Romanovsky wrote: >

Re: [PATCH rdma-next 00/24] Extend DEVX functionality

On Mon, Sep 17, 2018 at 10:34 PM, Leon Romanovsky wrote: > On Mon, Sep 17, 2018 at 02:03:53PM +0300, Leon Romanovsky wrote: >> From: Leon Romanovsky >> >> From Yishai, >> >> This series comes to enable the DEVX functionality in some wider scope, >> specifically, >> - It enables using kernel

Re: [RFC PATCH net-next v1 00/14] rename and shrink i40evf

On Fri, Sep 14, 2018 at 1:31 AM, Jesse Brandeburg wrote: Hi Jesse, > This series contains changes to i40evf so that it becomes a more > generic virtual function driver for current and future silicon. > > While doing the rename of i40evf to a more generic name of iavf, > we also put the driver

Re: [PATCH mlx5-next v1 05/15] net/mlx5: Break encap/decap into two separated flow table creation flags

On Thu, Sep 6, 2018 at 7:09 AM, Leon Romanovsky wrote: > On Thu, Sep 06, 2018 at 12:37:17AM +0300, Or Gerlitz wrote: >> On Wed, Sep 5, 2018 at 9:11 PM, Leon Romanovsky wrote: >> > On Wed, Sep 05, 2018 at 10:38:00AM -0600, Jason Gunthorpe wrote: >> >> On Wed, Se

Re: [PATCH mlx5-next v1 05/15] net/mlx5: Break encap/decap into two separated flow table creation flags

On Wed, Sep 5, 2018 at 9:11 PM, Leon Romanovsky wrote: > On Wed, Sep 05, 2018 at 10:38:00AM -0600, Jason Gunthorpe wrote: >> On Wed, Sep 05, 2018 at 08:10:25AM +0300, Leon Romanovsky wrote: >> > > > - int en_encap_decap = !!(flags & MLX5_FLOW_TABLE_TUNNEL_EN); >> > > > + int en_encap

Re: phys_port_id in switchdev mode?

On Tue, Sep 4, 2018 at 1:20 PM, Jakub Kicinski wrote: > On Mon, 3 Sep 2018 12:40:22 +0300, Or Gerlitz wrote: >> On Tue, Aug 28, 2018 at 9:05 PM, Jakub Kicinski wrote: >> > Hi! >> >> Hi Jakub and sorry for the late reply, this crazigly hot summer refuses to >&

Re: phys_port_id in switchdev mode?

On Fri, Aug 31, 2018 at 11:13 PM, Marcelo Ricardo Leitner wrote: > On Tue, Aug 28, 2018 at 08:43:51PM +0200, Jakub Kicinski wrote: >> Ugh, CC: netdev.. >> >> On Tue, 28 Aug 2018 20:05:39 +0200, Jakub Kicinski wrote: >> > Hi! >> > >> > I wonder if we can use phys_port_id in switchdev to group

Re: phys_port_id in switchdev mode?

On Tue, Aug 28, 2018 at 9:05 PM, Jakub Kicinski wrote: > Hi! Hi Jakub and sorry for the late reply, this crazigly hot summer refuses to die, Note I replied couple of minutes ago but it didn't get to the list, so lets take it from this one: > I wonder if we can use phys_port_id in switchdev to

Re: [net-next 03/12] net/mlx5e: Ethtool steering, ip6 support

On Sat, Aug 11, 2018 at 1:26 AM, Saeed Mahameed wrote: > Add ip6 support for ethtool flow steering. > > New supported flow types: ip6|tcp6|udp6| > Supported fields: src-ip|dst-ip|src-port|dst-port > > Signed-off-by: Saeed Mahameed > --- > .../mellanox/mlx5/core/en_fs_ethtool.c| 138

Re: [PATCH net-next 2/6] nfp: flower: allow matching on ipv4 UDP tunnel tos and ttl

On Tue, Aug 7, 2018 at 6:35 PM, Simon Horman wrote: > From: John Hurley > > The addition of FLOW_DISSECTOR_KEY_ENC_IP to TC flower means that the ToS > and TTL of the tunnel header can now be matched on. > > Extend the NFP tunnel match function to include these new fields. (referring to you

Re: [PATCH net-next 4/6] net/sched: allow flower to match tunnel options

On Tue, Aug 7, 2018 at 6:36 PM, Simon Horman wrote: > From: Pieter Jansen van Vuuren > > Allow matching on options in Geneve tunnel headers. > This makes use of existing tunnel metadata support. > > The options can be described in the form > CLASS:TYPE:DATA/CLASS_MASK:TYPE_MASK:DATA_MASK, where

Re: [net-next PATCH] net: ipv4: fix listify ip_rcv_finish in case of forwarding

On Wed, Jul 11, 2018 at 11:06 PM, Jesper Dangaard Brouer wrote: > On Wed, 11 Jul 2018 19:05:20 + > Saeed Mahameed wrote: > >> On Wed, 2018-07-11 at 17:01 +0200, Jesper Dangaard Brouer wrote: >> > Only driver sfc actually uses this, but I don't have this NIC, so I >> > tested this on mlx5,

[PATCH net-next 0/3] net/mlx5: Offload setting/matching on tunnel tos/ttl

This series enables mlx5 offloading of tc eswitch rules that set tos/ttl (encap) or match on them (decap) for tunnels. Or Gerlitz (3): net/mlx5e: Use ttl from route lookup on tc encap offload only if needed net/mlx5e: Support setup of tos and ttl for tunnel key TC action offload net/mlx5e

[PATCH net-next 1/3] net/mlx5e: Use ttl from route lookup on tc encap offload only if needed

Currnetly, the ttl for the encapsulation headers is taken from the route lookup result. As a pre-step to allow for an offload case when the user specifies the ttl, take it from the route lookup only if not zero. While here, also move to use u8 instead int for the ttl. Signed-off-by: Or Gerlitz

[PATCH net-next 2/3] net/mlx5e: Support setup of tos and ttl for tunnel key TC action offload

Use the values provided by user-space for the encapsulation headers. Signed-off-by: Or Gerlitz Reviewed-by: Roi Dayan --- drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 21 - 1 files changed, 12 insertions(+), 9 deletions(-) diff --git a/drivers/net/ethernet/mellanox

[PATCH net-next 3/3] net/mlx5e: Offload TC matching on tos/ttl for ip tunnels

Enable offloading of TC matching on tos/ttl for ipv4/6 tunnels. Signed-off-by: Or Gerlitz Reviewed-by: Roi Dayan --- drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 23 ++- 1 files changed, 22 insertions(+), 1 deletions(-) diff --git a/drivers/net/ethernet/mellanox

Re: [PATCH iproute2/next 1/2] tc/act_tunnel_key: Enable setup of tos and ttl

On Thu, Jul 19, 2018 at 2:48 PM, Roman Mashak wrote: > Or Gerlitz writes: > >> Allow to set tos and ttl for the tunnel. >> >> For example, here's encap rule that sets tos to the tunnel: >> >> tc filter add dev eth0_0 protocol ip parent : prio 10 flow

[PATCH iproute2/next 1/2] tc/act_tunnel_key: Enable setup of tos and ttl

dst_port 4789 tos 0x30 \ action mirred egress redirect dev vxlan_sys_4789 Signed-off-by: Or Gerlitz Reviewed-by: Roi Dayan Acked-by: Jiri Pirko --- include/uapi/linux/tc_act/tc_tunnel_key.h |2 + man/man8/tc-tunnel_key.8 |8 tc/m_tunnel_key.c

[PATCH iproute2/next 0/2] set/match the tos/ttl fields of TC based IP tunnels

/cover/945216/ Or Gerlitz (2): tc/act_tunnel_key: Enable setup of tos and ttl tc/flower: Add match on encapsulating tos/ttl include/uapi/linux/pkt_cls.h |5 +++ include/uapi/linux/tc_act/tc_tunnel_key.h |2 + man/man8/tc-flower.8 | 14 +++- man

[PATCH iproute2/next2/next 2/2] tc/flower: Add match on encapsulating tos/ttl

\ src_mac e4:11:22:33:44:70 dst_mac e4:11:22:33:44:50 \ action tunnel_key unset \ action mirred egress redirect dev eth0_0 Signed-off-by: Or Gerlitz Reviewed-by: Roi Dayan Acked-by: Jiri Pirko --- include/uapi/linux/pkt_cls.h |5 + man/man8/tc-flower.8 | 14 +- tc

Re: [net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets

On Thu, Jul 19, 2018 at 12:02 PM, Eran Ben Elisha wrote: > On Thu, Jul 19, 2018 at 10:50 AM, Or Gerlitz wrote: >> On Thu, Jul 19, 2018 at 9:55 AM, Eran Ben Elisha >> wrote: >>> On Thu, Jul 19, 2018 at 9:23 AM, Or Gerlitz wrote: >>>> On Thu, Jul 19, 2018 at

Re: [net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets

On Thu, Jul 19, 2018 at 9:55 AM, Eran Ben Elisha wrote: > On Thu, Jul 19, 2018 at 9:23 AM, Or Gerlitz wrote: >> On Thu, Jul 19, 2018 at 4:26 AM, Saeed Mahameed wrote: >>> From: Eran Ben Elisha >>> >>> Driver is yet to support aRFS for encapsulated packets,

Re: [net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets

On Thu, Jul 19, 2018 at 4:26 AM, Saeed Mahameed wrote: > From: Eran Ben Elisha > > Driver is yet to support aRFS for encapsulated packets, return early > error in such case. Eran, Isn't that something which is done wrong by the arfs stack code? If the kernel has an SKB which has encap set

[PATCH net-next 1/3] net/sched: tunnel_key: Allow to set tos and ttl for tc based ip tunnels

Allow user-space to provide tos and ttl to be set for the tunnel headers. Signed-off-by: Or Gerlitz Reviewed-by: Roi Dayan Acked-by: Jiri Pirko --- include/uapi/linux/tc_act/tc_tunnel_key.h | 2 ++ net/sched/act_tunnel_key.c| 20 ++-- 2 files changed, 20

[PATCH net-next 3/3] net/sched: cls_flower: Support matching on ip tos and ttl for tunnels

Allow users to set rules matching on ipv4 tos and ttl or ipv6 traffic-class and hoplimit of tunnel headers. Signed-off-by: Or Gerlitz Reviewed-by: Roi Dayan Acked-by: Jiri Pirko --- include/uapi/linux/pkt_cls.h | 5 + net/sched/cls_flower.c | 43

[PATCH net-next 2/3] flow_dissector: Dissect tos and ttl from the tunnel info

Add dissection of the tos and ttl from the ip tunnel headers fields in case a match is needed on them. Signed-off-by: Or Gerlitz Reviewed-by: Roi Dayan Acked-by: Jiri Pirko --- include/net/flow_dissector.h | 2 +- net/core/flow_dissector.c| 14 +- 2 files changed, 14

[PATCH net-next 0/3] set/match the tos/ttl fields of TC based IP tunnels

enc_dst_ip 192.168.10.1 enc_key_id 100 enc_dst_port 4789 enc_tos 0x30 \ src_mac e4:11:22:33:44:70 dst_mac e4:11:22:33:44:50 \ action tunnel_key unset \ action mirred egress redirect dev eth0_0 Or. Or Gerlitz (3): net/sched: tunnel_key: Allow to set tos and ttl for tc

Re: [RFC PATCH rdma-next 13/18] RDMA/mlx5: Enable decap and packet reformat on flow tables

On Tue, Jul 17, 2018 at 12:46 AM, Mark Bloch wrote: >> From: Or Gerlitz [mailto:gerlitz...@gmail.com] >> > If NIC RX flow tables support decap opertion, enable it on creation. >> opertion --> operation saw it? >> > If NIC TX flow tables support reforma

Re: [RFC PATCH mlx5-next 07/18] net/mlx5: Expose new packet reformat capabilities

On Mon, Jul 16, 2018 at 11:22 AM, Leon Romanovsky wrote: > From: Mark Bloch > > Expose new abilities when creating a packet reformat context. > > The new types which can be created are: > MLX5_REFORMAT_TYPE_L2_TO_L2_TUNNEL: Ability to create generic encap > opertion to be done by the HW.

Re: [RFC PATCH mlx5-next 04/18] net/mlx5: Break encap/decap into two separated flags

On Mon, Jul 16, 2018 at 11:22 AM, Leon Romanovsky wrote: > From: Mark Bloch > > Today we are able to attach encap and decap actions only to the FDB. > In preparation to enable those actions on the NIC flow tables break tables break --> tables, break > the single flag into two.

Re: [RFC PATCH mlx5-next 02/18] net/mlx5: Export modify header alloc/dealloc functions

On Mon, Jul 16, 2018 at 11:22 AM, Leon Romanovsky wrote: > From: Mark Bloch > > Those function will be used by the RDMA side to create modify header function --> functions > actions to be attached to flow steering rules via verbs.

Re: [RFC PATCH rdma-next 13/18] RDMA/mlx5: Enable decap and packet reformat on flow tables

On Mon, Jul 16, 2018 at 11:23 AM, Leon Romanovsky wrote: > From: Mark Bloch > > If NIC RX flow tables support decap opertion, enable it on creation. opertion --> operation > If NIC TX flow tables support reformat opertion, enable it on creation. What is the trigger to use the decap flag on RX

Re: [RFC PATCH mlx5-next 01/18] net/mlx5: Add proper NIC TX steering flow tables support

On Mon, Jul 16, 2018 at 11:22 AM, Leon Romanovsky wrote: > From: Mark Bloch > > Expose the ability to add steering rules to NIC TX flow tables. > For now, we are only adding TX bypass (egress) which is used by the RDMA > side. While we are here clean the switch logic. > > We expose the same

Re: [PATCH mlx5-next v1 1/8] net/mlx5: Add forward compatible support for the FTE match data

On Sun, Jul 15, 2018 at 10:26 AM, Yishai Hadas wrote: > On 7/12/2018 11:53 PM, Or Gerlitz wrote: >> On Wed, Jul 11, 2018 at 2:10 PM, Leon Romanovsky wrote: >>> From: Yishai Hadas >>> Use the PRM size including the reserved when working with the FTE >>> ma

Re: [PATCH net-next] net: sched: refactor flower walk to iterate over idr

On Tue, Jul 10, 2018 at 8:02 PM, Vlad Buslov wrote: > > On Tue 10 Jul 2018 at 13:55, Simon Horman wrote: >> On Mon, Jul 09, 2018 at 01:29:11PM +0300, Vlad Buslov wrote: >>> Extend struct tcf_walker with additional 'cookie' field. It is intended to >>> be used by classifier walk implementations

Re: [PATCH mlx5-next v1 2/8] net/mlx5: Add support for flow table destination number

On Fri, Jul 13, 2018 at 12:26 AM, Jason Gunthorpe wrote: > On Fri, Jul 13, 2018 at 12:00:41AM +0300, Or Gerlitz wrote: >> On Wed, Jul 11, 2018 at 2:10 PM, Leon Romanovsky wrote: >> > From: Yishai Hadas >> > >> > Add support to set a destination from a flow t

Re: [PATCH mlx5-next v1 2/8] net/mlx5: Add support for flow table destination number

On Wed, Jul 11, 2018 at 2:10 PM, Leon Romanovsky wrote: > From: Yishai Hadas > > Add support to set a destination from a flow table number. > This functionality will be used in downstream patches from this > series by the DEVX stuff. Reading your cover letter, I still don't understand what is

Re: [PATCH mlx5-next v1 1/8] net/mlx5: Add forward compatible support for the FTE match data

On Wed, Jul 11, 2018 at 2:10 PM, Leon Romanovsky wrote: > From: Yishai Hadas > > Use the PRM size including the reserved when working with the FTE > match data. is this actually a bug fix? > This comes to support forward compatibility for cases that current > reserved data will be exposed by

Re: [net-next PATCH] net: ipv4: fix listify ip_rcv_finish in case of forwarding

On Wed, Jul 11, 2018 at 11:06 PM, Jesper Dangaard Brouer wrote: > Well, I would prefer you to implement those. I just did a quick > implementation (its trivially easy) so I have something to benchmark > with. The performance boost is quite impressive! sounds good, but wait > One reason I

Re: [BUG] mlx5 have problems with ipv4-ipv6 tunnels in linux 4.4

On Tue, Jul 10, 2018 at 12:19 PM, Konstantin Khlebnikov wrote: > On 10.07.2018 01:31, Saeed Mahameed wrote: >> >> On Tue, Jul 3, 2018 at 10:45 PM, Konstantin Khlebnikov >> wrote: >>> >>> I'm seeing problems with tunnelled traffic with Mellanox Technologies >>> MT27710 Family [ConnectX-4 Lx]

Re: [PATCH 0/6] offload Linux LAG devices to the TC datapath

On Thu, Jun 28, 2018 at 7:02 AM, Jakub Kicinski wrote: [...] > } else if (netif_is_lag_master(out_dev) && >priv->flower_ext_feats & NFP_FL_FEATS_LAG) { > int gid; > > output->flags = cpu_to_be16(tmp_flags); > gid =

Re: [PATCH 0/6] offload Linux LAG devices to the TC datapath

On Thu, Jun 28, 2018 at 2:08 AM, Jakub Kicinski wrote: > On Wed, 27 Jun 2018 23:07:29 +0300, Or Gerlitz wrote: >> On Wed, Jun 27, 2018 at 1:31 AM, Jakub Kicinski >> wrote: >> > On Tue, 26 Jun 2018 17:57:08 +0300, Or Gerlitz wrote: >> >> >> 2. re the egre

Re: Fwd: [PATCH 0/6] offload Linux LAG devices to the TC datapath

On Tue, Jun 26, 2018 at 9:16 PM, John Hurley wrote: > On Tue, Jun 26, 2018 at 3:57 PM, Or Gerlitz wrote: >>> Forwarded Message >>> Subject: [PATCH 0/6] offload Linux LAG devices to the TC datapath >>> Date: Thu, 21 Jun 2018 14:35:55 +0100 &g

Re: [PATCH 0/6] offload Linux LAG devices to the TC datapath

On Wed, Jun 27, 2018 at 1:31 AM, Jakub Kicinski wrote: > On Tue, 26 Jun 2018 17:57:08 +0300, Or Gerlitz wrote: >> 2. re the egress side of things. Some NIC HWs can't just use LAG >> as the egress port destination of an ACL (tc rule) and the HW rule >> needs to be duplicated

Re: Fwd: [PATCH 0/6] offload Linux LAG devices to the TC datapath

> Forwarded Message > Subject: [PATCH 0/6] offload Linux LAG devices to the TC datapath > Date: Thu, 21 Jun 2018 14:35:55 +0100 > From: John Hurley > To: d...@openvswitch.org, r...@mellanox.com, g...@mellanox.com, > pa...@mellanox.com, f...@sysclose.org,

Re: [PATCH net] net: sched: cls: Fix offloading when ingress dev is vxlan

On Wed, Jun 6, 2018 at 6:50 PM, Jakub Kicinski wrote: > On Wed, 6 Jun 2018 08:12:20 +0300, Or Gerlitz wrote: >> On Tue, Jun 5, 2018 at 9:59 PM, Jakub Kicinski wrote: >> > But the correct fix is to remove egdev crutch completely IMO. >> Not against it, sometim

Re: [PATCH net] net: sched: cls: Fix offloading when ingress dev is vxlan

On Wed, Jun 6, 2018 at 12:27 AM, Jakub Kicinski wrote: > On Tue, 05 Jun 2018 15:06:40 -0400 (EDT), David Miller wrote: >> From: Jakub Kicinski >> Date: Tue, 5 Jun 2018 11:57:47 -0700 >> >> > Do we still care about correctness and not breaking backward >> > compatibility? >> >> Jakub let me know

Re: [PATCH net] net: sched: cls: Fix offloading when ingress dev is vxlan

On Tue, Jun 5, 2018 at 9:59 PM, Jakub Kicinski wrote: > On Tue, 5 Jun 2018 11:57:47 -0700, Jakub Kicinski wrote: >> On Tue, 5 Jun 2018 11:04:03 +0300, Paul Blakey wrote: >> > When using a vxlan device as the ingress dev, we count it as a >> > "no offload dev", so when such a rule comes and err

Re: [net-next 00/12][pull request] Intel Wired LAN Driver Updates 2018-06-04

On Mon, Jun 4, 2018 at 11:30 PM, David Miller wrote: > It's open a day or two more to deal with the AF_XDP issues... Dave, Just to make sure, is the AF_XDP ZC (Zero Copy) UAPI going to be merged for this window -- AFAIU from [1], it's still under examination/development/research for non Intel

Re: [net-next 00/12][pull request] Intel Wired LAN Driver Updates 2018-06-04

On Mon, Jun 4, 2018 at 8:56 PM, Jeff Kirsher wrote: > This series contains a smorgasbord of updates to documentation, e1000e, > igb, ixgbe, ixgbevf and i40e. Dave, Did you forgot to flip the sign on the shop's door [1]? Or. [1] http://vger.kernel.org/~davem/net-next.html

Re: [RFC net-next 0/4] net: sched: support replay of filter offload when binding to block

On Mon, May 28, 2018 at 11:02 PM, Jakub Kicinski wrote: > On Mon, 28 May 2018 13:48:28 +0300, Or Gerlitz wrote: >> On Fri, May 25, 2018 at 5:25 AM, Jakub Kicinski wrote: >> > This series from John adds the ability to replay filter offload requests >> > when ne

Re: [PATCH RESEND rdma-next] net/mlx5: Use flow counter pointer as input to the query function

On Wed, May 30, 2018 at 9:59 AM, Leon Romanovsky wrote: > > Care to pass it through our usual submission channel? sure, Jason asked for a fixup, I will push it internally Or.

[PATCH RESEND rdma-next] net/mlx5: Use flow counter pointer as input to the query function

This allows to un-expose the details of struct mlx5_fc and keep it internal to the core driver as it used to be. Signed-off-by: Or Gerlitz --- Jason, As you asked, I am sending a fixup in case you intend to apply V2 of the flow counter series [1], if there's going to be V3, Leon, please apply

[PATCH rdma-next] net/mlx5: Use flow counter pointer as input to the query function

This allows to un-expose the details of struct mlx5_fc and keep it internal to the core driver as it used to be. Change-Id: I780cd74863fa2beccdd52e7d0cdd1e117a5aa353 Signed-off-by: Or Gerlitz --- Jason, As you asked, I am sending a fixup in case you intend to apply V2 of the flow counter

Re: [RFC net-next 0/4] net: sched: support replay of filter offload when binding to block

On Fri, May 25, 2018 at 5:25 AM, Jakub Kicinski wrote: > This series from John adds the ability to replay filter offload requests > when new offload callback is being registered on a TC block. This is most > likely to take place for shared blocks today, when a block

Re: [PATCH mlx5-next v1 02/13] net/mlx5: Export flow counter related API

On Sun, May 27, 2018 at 1:23 PM, Leon Romanovsky wrote: > From: Raed Salem > > Exports counters API to be used in both IB and EN. > > Reviewed-by: Yishai Hadas > Signed-off-by: Raed Salem > Signed-off-by: Leon

Re: [net-next 2/6] net/mlx5: Add pbmc and pptb in the port_access_reg_cap_mask

On Tue, May 22, 2018 at 7:01 PM, Saeed Mahameed <sae...@dev.mellanox.co.il> wrote: > On Tue, May 22, 2018 at 3:21 AM, Or Gerlitz <gerlitz...@gmail.com> wrote: >> On Tue, May 22, 2018 at 1:19 PM, Or Gerlitz <gerlitz...@gmail.com> wrote: >>> On Tue, May 22, 2

Re: [PATCH net-next 0/8] nfp: offload LAG for tc flower egress

On Thu, May 24, 2018 at 9:49 PM, Jakub Kicinski <jakub.kicin...@netronome.com> wrote: > On Thu, 24 May 2018 20:04:56 +0300, Or Gerlitz wrote: >> Does this apply also to non-uplink representors? if yes, what is the use >> case? >> >> We are looking on support

Re: [PATCH net-next 8/8] nfp: flower: compute link aggregation action

On Thu, May 24, 2018 at 5:22 AM, Jakub Kicinski wrote: > From: John Hurley > > If the egress device of an offloaded rule is a LAG port, then encode the > output port to the NFP with a LAG identifier and the offloaded group ID. > > A prelag

Re: [PATCH net-next 0/8] nfp: offload LAG for tc flower egress

On Thu, May 24, 2018 at 5:22 AM, Jakub Kicinski wrote: > Hi! > > This series from John adds bond offload to the nfp driver. Patch 5 > exposes the hash type for NETDEV_LAG_TX_TYPE_HASH to make sure nfp > hashing matches that of the software LAG. This may be

[PATCH net] net : sched: cls_api: deal with egdev path only if needed

switchdev scheme, a user rule of VFR A --> VFR B will end up with two HW rules (1) VF A --> VF B and (2) uplink --> VF B Fixes: 208c0f4b5237 ('net: sched: use tc_setup_cb_call to call per-block callbacks') Signed-off-by: Or Gerlitz <ogerl...@mellanox.com> --- Hi Dave, As I w

Re: [net-next 1/6] net/dcb: Add dcbnl buffer attribute

On Wed, May 23, 2018 at 4:01 AM, Huy Nguyen wrote: > Dear Jakub, PSB. > On 5/22/2018 1:32 PM, Jakub Kicinski wrote: >> Devlink API accommodates requirements of simpler (SwitchX2?) and more >> advanced schemes (present in Spectrum). The simpler/basic static >> threshold

Re: [PATCH net-next 00/13] nfp: abm: add basic support for advanced buffering NIC

On Tue, May 22, 2018 at 10:56 AM, Jakub Kicinski <jakub.kicin...@netronome.com> wrote: > On Mon, May 21, 2018 at 11:32 PM, Or Gerlitz wrote: >> On Tue, May 22, 2018 at 8:12 AM, Jakub Kicinski wrote: >>> Hi! >>> >>> This series lays groundwork

Re: [net-next 2/6] net/mlx5: Add pbmc and pptb in the port_access_reg_cap_mask

On Tue, May 22, 2018 at 1:19 PM, Or Gerlitz <gerlitz...@gmail.com> wrote: > On Tue, May 22, 2018 at 12:04 AM, Saeed Mahameed <sae...@mellanox.com> wrote: >> From: Huy Nguyen <h...@mellanox.com> >> >> Add pbmc and pptb in the port_access_reg_cap_mask. These t

Re: [net-next 2/6] net/mlx5: Add pbmc and pptb in the port_access_reg_cap_mask

On Tue, May 22, 2018 at 12:04 AM, Saeed Mahameed wrote: > From: Huy Nguyen > > Add pbmc and pptb in the port_access_reg_cap_mask. These two > bits determine if device supports receive buffer configuration. > > Signed-off-by: Huy Nguyen

Re: [PATCH net-next 00/13] nfp: abm: add basic support for advanced buffering NIC

On Tue, May 22, 2018 at 8:12 AM, Jakub Kicinski wrote: > Hi! > > This series lays groundwork for advanced buffer management NIC feature. > It makes necessary NFP core changes, spawns representors and adds devlink > glue. Following series will add the actual

Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions

On Mon, May 21, 2018 at 12:33 AM, Marcelo Ricardo Leitner <marcelo.leit...@gmail.com> wrote: > On Mon, May 21, 2018 at 12:13:06AM +0300, Or Gerlitz wrote: >> On Sun, May 20, 2018 at 1:20 AM, Marcelo Ricardo Leitner >> <marcelo.leit...@gmail.com> wrote: >> > On M

Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions

On Sun, May 20, 2018 at 1:20 AM, Marcelo Ricardo Leitner wrote: > On Mon, May 14, 2018 at 05:27:14PM +0300, Vlad Buslov wrote: >> Substitute calls to action insert function with calls to action insert >> unique function that warns if insertion overwrites index in idr. >

Re: [patch net-next] nfp: flower: set sysfs link to device for representors

On Thu, May 17, 2018 at 1:05 PM, Jiri Pirko wrote: > From: Jiri Pirko > > Do this so the sysfs has "device" link correctly set. please no This is likely to create bunch of issues with respect to how libvirt deals with the representors. We were discussing

  1   2   3   4   5   6   7   8   9   10   >