On Fri, Jun 02, 2017 at 12:08:39PM -0400, David Miller wrote: > From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> > Date: Fri, 2 Jun 2017 09:06:43 -0700 > > > On Fri, Jun 02, 2017 at 06:39:40PM +0300, Leon Romanovsky wrote: > >> On Thu, Jun 01, 2017 at 06:57:59PM -0400, Doug Ledford wrote: > >> > On Thu, 2017-05-25 at 12:02 -0400, David Miller wrote: > >> > > From: Saeed Mahameed <saeedm@xxxxxxxxxxxx> > >> > > Date: Tue, 23 May 2017 14:43:58 +0300 > >> > > > >> > > > Hi Dave and Doug, > >> > > > > >> > > > This series introduces some small updates and FPGA support to the > >> > > mlx5 > >> > > > core/ethernet and IB drivers. > >> > > > > >> > > > For more details please see below. > >> > > > > >> > > > Please pull and let me know if there's any problem. > >> > > > >> > > Ok, I've pulled this into net-next. > >> > > > >> > > Doug let me know if there are any merge hassles we need to coordinate > >> > > on. > >> > > > >> > > Thanks. > >> > > >> > Will do. But is the question of a possible revert settled? Because > >> > once I pull, a revert means I have to pull all the way up to the revert > >> > as well... > >> > >> Revert is unlikely to happen, Saeed is working with Alexey to resolve > >> his raised concerns. > > > > I still think the direction is absolutely wrong. > > Reinventing fpga interfaces via nic driver is no-go. > > mlx needs to send a patch to revert it to show that they are willing > > to listen to the community. > > "Two people from Facebook" is not the commnity Alexei. :-) I've read the thread that fpga folks are not excited about fpga behind the nic either... but yeah i'm mainly expressing my opinions here. > And ironically, you guys will want to be one of the main users of > these facilities for the KTLS offload bits, so the desire to separate > it out and make "backports easier" really confuses me. We will not be using ktls offload via hidden fpga which is not properly exposed to the kernel. We've learned our lesson with eswitch. ktls patches are independent of hw offload. It's great that mlx fpga can accelerate ktls tx which is extra confirmation that ktls api is on the right track. There is still 'ktls rx' to finish and 'ktls rx offload' is even trickier, since it's more intrusive into the core networking. Once crypto scatter gather is improved, we expect to see 8% perf gain out of sw ktls alone. So ktls hw offload is complementary and not mandatory. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
