On Tue, Jun 06, 2017 at 03:01:51PM -0400, David Miller wrote:
From: Alexei Starovoitov <redacted>
Date: Tue, 6 Jun 2017 11:55:33 -0700
quoted
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.
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...
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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 06, 2017 at 03:44:53PM -0700, Alexei Starovoitov wrote:
On Tue, Jun 06, 2017 at 03:01:51PM -0400, David Miller wrote:
quoted
From: Alexei Starovoitov <redacted>
Date: Tue, 6 Jun 2017 11:55:33 -0700
quoted
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.
It is probably over-engineered for a single frog, but maybe you could
use a modified RFC 2795?
Andrew
On Wed, Jun 7, 2017 at 1:44 AM, Alexei Starovoitov
[off-list ref] wrote:
On Tue, Jun 06, 2017 at 03:01:51PM -0400, David Miller wrote:
quoted
From: Alexei Starovoitov <redacted>
Date: Tue, 6 Jun 2017 11:55:33 -0700
quoted
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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html