[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ3xEMjNvYRoVhi3+ojmdiMf8x_px8VDWTkBnKqoDNLF2N-51w@mail.gmail.com>
Date: Sat, 3 Jun 2017 22:46:50 +0300
From: Or Gerlitz <gerlitz.or@...il.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: David Miller <davem@...emloft.net>,
Leon Romanovsky <leon@...nel.org>,
Doug Ledford <dledford@...hat.com>,
Saeed Mahameed <saeedm@...lanox.com>,
Linux Netdev List <netdev@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
Ilan Tayari <ilant@...lanox.com>
Subject: Re: [pull request][for-next 0/6] Mellanox mlx5 updates 2017-05-23
On Fri, Jun 2, 2017 at 7:57 PM, Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
> Back to eswitch analogy. All I hear from mlx is "at this stage
> it's not approriate ...". Well, I've been asking to do
> 'the right thing' for eswitch for months now and eswitch was
> in the driver for years. What are the chances that this fpga
> will ever be exposed? Once the code is merged there is no
> incentive for the vendor to do it differently.
Alexei, can you please clarify the claims re eswitch? are you
referring to the interfaces to program SRIOV eswitch? if not, what?
Or.
Powered by blists - more mailing lists