On Tue, Jun 06, 2017 at 01:47:26PM -0400, David Miller wrote: > From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> > Date: Tue, 6 Jun 2017 10:42:35 -0700 > > > so it's like rdma, but without using kernel rdma stack? > > No sockets here, just transformation rules. It's like offloading > a complex TC rule to hardware version of that transformation. > > Yes, there is state, but I argue that it is no different than TC > offloading rules. What if TC had "hash" and "crypt" operations > and we attached them to appropriate u32 matches? You wouldn't > be able to tell the difference. there is huge difference in underlying hw. fpga is a separate device with its own phy and mac layers, its own queues, packet parsing and rdma logic. Where as tc offload is happening within the same hw queues/memory/stats management logic. My understanding that when I do 'ethtool -L' to change number of queues or 'ethtool -G' it changes the memory layout that tc offload is operating on as well. When I do 'ethtool -S' it shows me the stats for the device that tc offload rules are integral part of. Whereas fpga is a different physical device with its own buffers and such. We can add 'ethtool -G_fpga, -L_fpga', etc but this type of discussion needs to happen _before_ the whole thing is merged. It will never happen after the fact. Just look at mlx responses, they still don't acknowledge the issue and instead pushing for ipsec, tls (in other words: new features) instead of addressing production issues that are obviously not glamorous to work on and fix. > I think you are way over-obsessed with this FPGA offload thing, > quite frankly. if we didn't have issues with eswitch that drops packets and we don't even know how many, I wouldn't be complaining. There is a discussion going on to add few counters for eswitch visibility, but it's taking forever and it's not at the point of exposing eswitch as a kernel object. Why? because it's hard to refactor it now into something like devlink or whatever new abstraction that would be needed. -- 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
