> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> ow...@vger.kernel.org] On Behalf Of Doug Ledford
> These patches add the concept of duplicate GIDs that are differentiated by
> their RoCE version (also called network type). So, now, an incoming packet
> could match a couple different gid_indexes and we need additional
> information to get back to the definitive 1:1 mapping. The submitted patches
> are designed around a lazy resolution of the namespace, preferring to defer
> the work of mapping the incoming packet to a unique namespace until that
> information is actually needed. To enable this lazy resolution, it provides
> the
> network_type so that the resolution can be done.
>
> This is a fair assessment of the current state of things and what these
> patches do, yes?
Hi Doug,
Yes, your description nails the crux of the discussion.
Thanks.
>
> Jason's objections are this:
>
> 1) The lazy resolution is wrong.
> 2) The use of network_type as the additional information to get to the
> unique namespace is vendor specific cruft that shouldn't be part of the core
> kernel API.
>
Which is totally wrong. RoCE versions and the network type attribute are part
of the RoCE specification.
There is nothing vendor specific. In fact, this patch initially came from
Avago!!!
> Jason's preference would be that the above issues be resolved by skipping
> the lazy resolution and instead doing proactive resolution on receipt of a
> packet and then probably just pass the namespace around instead of passing
> around the information needed to resolve the namespace. Or, at a
> minimum, at least make the information added to the core API not
> something vendor specific like network_type, which is a detail of the
> Mellanox implementation.
Again, there is nothing here specific to the Mellanox implementation.
This argument is invalid.
>
> Jason, is this accurate for your position?
>
> If everyone agrees that this is a fair statement of where we stand, then I'll
> continue my response. If not, please correct anything I have wrong above
> and I'll take that into my continued response.
>
Since we are following the standard, and:
- This is *not* a vendor specific issue
- Lazy resolution adheres to the current flow of the stack (which IMO, is the
right thing to do anyway)
- There are no security issues whatsoever (see below)
- The code could be easily extended to support namespaces in the future
- We should "release early release often", and not hold progress because of
endless philosophical discussions
then let's apply these patches.
I perfectly understand Jason's proposal and its merits.
I just don't agree that it is a better approach, and in any case this is not
the time to continue discussing it.
> 1 - Actually, for any received packet with associated IP address information.
> We've only enabled net namespaces for IP connections between user space
> applications, for direct IB connections or for kernel connections there is not
> yet any namespace support.
Correct.
That's why we are not risking anything in the KAPI with regard to namespaces;
there is no security issue.
--Liran
>
> --
> Doug Ledford <dledf...@redhat.com>
> GPG KeyID: 0E572FDD
>
N�����r��y����b�X��ǧv�^�){.n�+����{��ٚ�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�m��������zZ+�����ݢj"��!�i
