RE: switchdev fib offload issues

Hi Jiri, > Thoughts? One general thought comes to mind, regardless of your proposed solutions: You'll need to take care to propagate the error properly in case of routes created by the kernel, such as local routes. Local routes are created when an IP address is added to an interface, so in

RE: IPv6 IPSec incompatibilities between 2.6.23 and 3.6.18/4.6.4

> Node 1: fd01:1b10:1000::1 is running 4.6.4 > 14:21:50.737092 IP6 fd01:1b10:1000::3 > ff0e::1: > ESP(spi=0x0001,seq=0x100), length 136 > 14:21:51.737155 IP6 fd01:1b10:1000::3 > ff0e::1: > ESP(spi=0x0001,seq=0x101), length 136 ... > ip -s xfrm state > src fd01:1b10:1000::1 dst ff0e::1 >

RE: IPv6 IPSec incompatibilities between 2.6.23 and 3.6.18 (and probably later)

> On the receiving side (e.g. fd01:1b10:1000::1) I see the decrypted packets > with > the 2.6.23 kernel: > but NOT with the newer kernel: Hi Joerg, First steps to debug this would be: cat /proc/net/xfrm_stat ip -s xfrm state ip -s xfrm policy First command will show some error accounting,

RE: [patch net 5/9] mlxsw: spectrum: Add missing packet traps

> Add the following traps: > > 1) MTU Error: Trap packets whose size is bigger than the egress RIF's MTU. If > DF > bit isn't set, traffic will continue to be routed in slow path. > > 2) TTL Error: Trap packets whose TTL expired. This allows traceroute to work > properly. > > 3) OSPF packets.

[PATCH net] xfrm: Fix memory leak of aead algorithm name

uot;xfrm: Clone states properly on migration") without resolving this leak. This patch adds a kfree() call for the aead algorithm name. Fixes: 1a6509d99122 ("[IPSEC]: Add support for combined mode algorithms") Signed-off-by: Ilan Tayari <il...@mellanox.com> --- net/xfrm/x

RE: [PATCH] gso: Validate assumption of frag_list segementation

> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > > > From: Ilan Tayari <il...@mellanox.com> > > > > Commit 07b26c9454a2 ("gso: Support partial splitting at the frag_list > > pointer") assumes that all SKBs in a

XFRM pcpu cache issue

Hi Florian, I debugged a little the regression I told you about the other day... Steps and Symptoms: 1. Set up a host-to-host IPSec tunnel (or transport, doesn't matter) 2. Ping over IPSec, or do something to populate the pcpu cache 3. Join a MC group, then leave MC group 4. Try to ping again

RE: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly

> -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Subject: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly > > The new IPSec offload code introduced a build error: > > drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function >

RE: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly

s is a good fix. Values are now generated correctly. Sorry for the mixup. Thank you Arnd! Reviewed-by: Ilan Tayari <il...@mellanox.com>

RE: [PATCH] [net-next] net/mlx5: include wq.o in non-ethernet build for FPGA

> -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Subject: [PATCH] [net-next] net/mlx5: include wq.o in non-ethernet build > for FPGA > > Both the ethernet and FPGA portions of MLX5 now require the wq functions, > and we get a link error when CONFIG_MLX5_CORE_EN is

RE: [PATCH][-next] net/mlx5: fix spelling mistake: "Allodating" -> "Allocating"

lloc(struct mlx5_core_dev > *dev, int *gid_index) > if (index < 0) > return index; > > - mlx5_core_dbg(dev, "Allodating reserved GID %u\n", index); > + mlx5_core_dbg(dev, "Allocating reserved GID %u\n", index); > *gid_index = index; > return 0; > } > -- > 2.11.0 Thank you Colin for the fix. Reviewed-by: Ilan Tayari <il...@mellanox.com>

RE: [RFC net-next 9/9] xfrm: add a small xdst pcpu cache

> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > Subject: RE: [RFC net-next 9/9] xfrm: add a small xdst pcpu cache > > > -Original Message- > > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > > Subject:

RE: [RFC net-next 9/9] xfrm: add a small xdst pcpu cache

> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > Subject: [RFC net-next 9/9] xfrm: add a small xdst pcpu cache > > retain last used xfrm_dst in a pcpu cache. > On next request, reuse this dst if the policies are the same. > > The cache

RE: [PATCH 07/16] esp4: Reorganize esp_output

> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > Subject: [PATCH 07/16] esp4: Reorganize esp_output > > We need a fallback for ESP at layer 2, so split esp_output into generic > functions that can be used at layer 3 and layer 2 and use them

RE: XFRM pcpu cache issue

es the regression for me. Reported-by: Ayham Masood <ayh...@mellanox.com> Tested-by: Ilan Tayari <il...@mellanox.com> Thanks, Florian!

RE: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

> -Original Message- > From: Alexei Starovoitov [mailto:alexei.starovoi...@gmail.com] > > On Tue, May 23, 2017 at 02:44:02PM +0300, Saeed Mahameed wrote: > > From: Ilan Tayari <il...@mellanox.com> > > > > Mellanox Innova is a NIC with ConnectX and an

RE: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

> -Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > > On Fri, May 26, 2017 at 10:56:25AM -0700, Alexei Starovoitov wrote: > > > > for that feature which is the originating place, before defining > > > APIs/infrastructures, > > > until the feature is

RE: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

> -Original Message- > From: Jes Sorensen [mailto:jsoren...@fb.com] > > On 05/26/2017 04:29 AM, Saeed Mahameed wrote: > > On Thu, May 25, 2017 at 11:48 PM, Jes Sorensen wrote: > >> On 05/25/2017 06:40 AM, Saeed Mahameed wrote: > > Hi Jes, > > > > No, It is clearly

RE: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

t for Innova > > > > On Mon, May 29, 2017 at 03:58:33PM +, Ilan Tayari wrote: > > > > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > > > > Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for > > Innova > &

RE: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

> -Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova > > On Mon, May 29, 2017 at 03:58:33PM +0000, Ilan Tayari wrote: > > > From: Jason G

RE: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

> -Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova > > On Sun, May 28, 2017 at 07:22:27AM +0000, Ilan Tayari wrote: > > > This is neither PCI-bar map

RE: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

> -Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova > > On Mon, May 29, 2017 at 04:09:06PM +0000, Ilan Tayari wrote: > > > > For IPSec, this is alrea

RE: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

> -Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova > > On Sun, Jun 04, 2017 at 07:51:24AM +0000, Ilan Tayari wrote: > > > From: Jason G

RE: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

> -Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova > > > > This keep getting more ugly :( > > > > > > What about security? What if user space sends some raw packets to the > > >

RE: [PATCH net-next] net/esp4: Fix invalid esph pointer crash

> -Original Message- > From: Steffen Klassert [mailto:steffen.klass...@secunet.com] > > On Sun, Apr 30, 2017 at 04:34:38PM +0300, il...@mellanox.com wrote: > > From: Ilan Tayari <il...@mellanox.com> > > > > Both esp_output and esp_xmit take a poi