[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160621021836.GA81638@ast-mbp.thefacebook.com>
Date: Mon, 20 Jun 2016 19:18:38 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Saeed Mahameed <saeedm@....mellanox.co.il>
Cc: Saeed Mahameed <saeedm@...lanox.com>,
"David S. Miller" <davem@...emloft.net>,
Linux Netdev List <netdev@...r.kernel.org>,
Doug Ledford <dledford@...hat.com>,
Or Gerlitz <ogerlitz@...lanox.com>,
Maor Gottlieb <maorg@...lanox.com>,
Huy Nguyen <huyn@...lanox.com>, Tal Alon <talal@...lanox.com>,
Eric Dumazet <edumazet@...gle.com>,
Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [PATCH net-next 12/18] IB/mlx5: Add kernel offload flow-tag
On Sat, Jun 18, 2016 at 01:31:26AM +0300, Saeed Mahameed wrote:
>
> We simply want to selectively be able to see RoCE/RDMA ETH standard
> traffic in tcpdump, for diagnostic purposes.
> so in order to not overwhelm the kernel TCP/IP stack with this
> traffic, this patch in particular
> configures ConnectX4 hardware to tag those packets, so in downstream
> patches mlx5 netdevice will mark the SKBs of those packets
> to skip the TCP/IP stack and go only to tcpdump.
such 'feature' doesn't make sense to me.
'not overwhelming' kernel, but to 'overwhelm' userspace tcpdump?
Kernel can drop packets way faster than userspace, so such bypass
scheme has no prartical usage other than building a first step towards
complete dpdk-like bypass.
Powered by blists - more mailing lists