Date:   Mon, 9 Jul 2018 20:24:09 +0800
From:   Ka-Cheong Poon <ka-cheong.poon@...cle.com>
To:     Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc:     netdev@...r.kernel.org, santosh.shilimkar@...cle.com,
        davem@...emloft.net, rds-devel@....oracle.com
Subject: Re: [PATCH v2 net-next 0/3] rds: IPv6 support

On 07/06/2018 11:14 PM, Sowmini Varadhan wrote:

>>> - In net/rds/rds.h;
>>>
>>>    /* The following ports, 16385, 18634, 18635, are registered with IANA as
>>>     * the ports to be used for RDS over TCP and UDP.  18634 is the historical
>>>
>>>    What is "RDS over TCP and UDP"? There is no such thing as RDS-over-UDP.
>>>    IN fact RDS has nothing to do with UDP. The comment is confused. See next
>>>    item below, where the comment disappears.
>>
>>
>> As mentioned in the above comments, they are registered with IANA.
> 
> 16385 is registered for  RDS-TCP.


Yes, and it is noted in the comments.  The above comment is stating
the fact so that folks know what is already done when checking the
code.


> what does it mean to run rds-tcp and rds_rdma with the CM at the same time?
> Is this possible?  (if it is, why not poach some other number like 2049
> from NFS?!)


RDS can run over TCP and RDMA at the same time just like other
Internet services running over different transports.


> 18635 is actually not used in the RDS code.
> Why can you not use that for RDS_CM_PORT?


Just like any other Internet services, as long as a number is free,
it can use that number and register it with IANA.  There is no special
meaning about the number itself.  It is only a number to use and need
to be agreed on.  And the normal practice is that the same number be
used for a service running over different Internet transports.  This
is a good practice to avoid confusion.


> In general, please do NOT pull up these definitions into net/rds/rds.h
> They may change in the future- and the really belong in the transport
> specific header file - you question this further below, see my answer
> there.


If the number is changed, it will break compatibility.  Just like
any other Internet services, the registered service port number
won't change unless under very special circumstances.


>> There is no RDS/UDP in Linux but the port numbers are registered
>> nevertheless.  And RDS can work over UDP AFAICT.  BTW, it is really
> 
> No it cannot. RDS needs a reliable transport.  If you start using
> UDP (or pigeon-carrier) for the transport you have to build the
> reliability yourself.


As you noted above, if one build the reliability on top of UDP, one
can run RDS over UDP.  Is there something which is preventing RDS
to be run over other Internet transports?


> The Oracle DB libraries either use RDS-TCP or RDS-IB or UDP (in the UDP
> case they do their own congestion management in userspace, and
> history has shown that it is hard to get that right, thus the desire to
> switch to rds-tcp).


So RDS can in fact run over UDP and there is already an implementation.
Is there any problem with the comment then?


> Anyway, even though Andy Grover registered 18635 for "RDS-IB UDP",
> that is probably the most harmless one to use for this case, because
> - it is unused,
> - it calls itself rds-Infiniband,
> - the likelihood of doing rds-udp is infinitesmally small (it is more likely
>    that we will need to send packets from abc::1 -> fe80:2 before we need
>    rds-udp :-) :-) :-))
> - and if rds-udp happens, we can use 16385/udp for rds-udp
> 
> so please use 18635 for your RDS_CM_PORT and move it to IB specific
> header files and lets converge this thread.


I don't understand the rationale.  What is the problem of using 16385?
The above points do not show any problem in using this number.


> Towing RDS_TCP_PORT around has absolutely nothing to do with your
> ipv6 patch set.


Could you please elaborate this?  For example, is it a problem of
using port 80 for a HTPP web server running over SCTP?  I don't
believe there is.  It is a normal practice in Internet services.


>> strange that RDS/TCP does not use the port number already registered.
>> Anyway, the above comments are just a note on this fact in the IANA
> 
> 16385 was in defacto use for a long time (since 2.6 kernels), thus I
> registered it as well when I started fixing this up.


So this is a fix for a previous issue.  This is exactly the point
I made above.  The service port number won't change.  I think this
answers the "they may change in the future" point above.


> the 18634/18635 are registered for rds-iB, (caps intended) not rds-tcp.
> They are available for your use.


As there is really no problem is using 16385 and Oracle Linux is
already using it, I cannot agree on changing it.  It will just
cause inter-operability problem without any reason.


>> database.  The following is a link to the IANA assignment.
> 
> yes, I am aware
> 
>> IMHO, there should only be RDS_PORT in the first place.  And it
>> can be used for all transports.  For example, if RDS/SCTP is added,
>> it can also use the same port number.  There is no need to define
> 
> if/when we add rds/sctp, we shall keep that in mind.


This is the point of the comment.  I'm glad that it is noted.


> This is getting to be "arguing for the sake of arguing". I dont have
> the time for that.
> 
>> a new port number for each transport.  What is the rationale that
>> each transport needs to have its own number and be defined in its
>> own header file?
> 
> Some transports may not even need a port number. Some may need
> several. Some may use sysctl (suggested by Tom Herbert) to make
> this configurable. Until recently, we had rds/iWARP, that may need
> its own transport hooks, it does not make sense to peanut-butter
> that into the core module.
> 
> That is why it has to be in the transport. I hope that answers the
> question.


The above comment seems to suggest that any future extension of RDS
must make use of a port number and cannot be changed just because
a #define is put in the rds.h header file.  I cannot see how this
can be true.  Anyway, if just moving the #define to a different file
makes folks happier, I can do it to save time.



-- 
K. Poon
ka-cheong.poon@...cle.com

Powered by blists - more mailing lists