On Wed, Jun 7, 2017 at 1:44 AM, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > On Tue, Jun 06, 2017 at 03:01:51PM -0400, David Miller wrote: >> From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> >> Date: Tue, 6 Jun 2017 11:55:33 -0700 >> >> > If in the future mlx will make it into the nic in a way that >> > encryption shares all memory management logic and there is no fpga >> > at all then it indeed will be similar to tc offload. Right now it's >> > not and needs different sw architecture. >> >> If the visible effect is identical, I fundamentally disagree with you. >> >> I don't care if there is a frog sitting on the PHY that transforms >> the packets, it's all the same if the visible behavior is identical. > > that frog is a good example why we disagree. > I need to check the pulse of that frog and last time it ate. > In production I cannot have magical creatures do stuff for me. > I need to monitor all components, debug and mitigate the issues. Every HW vendor has his own magical creatures. you don't want just to have a kernel object representative for every HW unit! that's just not scalable. > If encryption is done by the nic, I get all the monitoring and > debugging as part of the standard tools. When it's a frog > hidden by the nic, I cannot do much when the fire erupts, > hence frog and production environment don't mix. > To move things forward... Let's assume there was no FPGA but the ASIC provided the encryption feature, and still a fire erupts, what would you have done differently ? Only the vendor will know how to debug regardless of what creature went nuts! Frog or a Cat the kernel shouldn't care much "it is all implementation details (HW implementation)", we should use the entry point to this device (PCI device/netdevice) as an abstraction point, and standardizing visibility/debuggability should be per 'kernel<->stack<->driver<->HW' features/flows/transactions. Having a full driver<->HW visibility/standardization eliminates the need of vendor specific drivers and each vendor should implement only standard HWs that can work with generic drivers. Re debuggability in ConnectX architecture, there is a well defined health reporting and monitoring mechanism between FW and driver. and it is up to the FW to check the pulse of every frog it is babysitting and report back to the driver. believe me you don't want the driver to know about every single wire in the chip. > how about marking the whole thing CONFIG_EXPERIMENTAL instead of revert? > Right now it's effectively non-production==experimental code and > I want to make it clear. > -- 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
