netdev - Re: [PATCH 0/26] Reliable Datagram Sockets (RDS), take 2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c0a09e5c0902251043x576e7066kb7aa76fc148a6f76@mail.gmail.com>
Date:	Wed, 25 Feb 2009 10:43:27 -0800
From:	Andrew Grover <andy.grover@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	andy.grover@...cle.com, netdev@...r.kernel.org,
	rds-devel@....oracle.com, general@...ts.openfabrics.org
Subject: Re: [PATCH 0/26] Reliable Datagram Sockets (RDS), take 2

On Tue, Feb 24, 2009 at 11:28 PM, David Miller <davem@...emloft.net> wrote:
> This makes RDMA too much of a first-class citizen in the networking
> stack.  That's a blocker for me.

RDS is not an RDMA protocol, it is a protocol that supports RDMA. RDS
is not an IB protocol, it is a protocol that supports IB transport.

RDS's reliable-datagram socket implementation has a modular interface
to the transport (e.g. tcp, udp, or ib) and works fine over transports
that do not support RDMA. (Most users also do not use RDMA.)

OK so we have:

1) RDS socket code
  must go in net/rds, it's socket code
2) RDS core rdma support
  move to drivers/infiniband?
3) RDS IB/iwarp transport
  keep the non-RDMA support in net/rds or move to d/i? It's not RDMA it's IB
4) IB/iwarp transport's rdma support
  move to d/i
5) RDS TCP transport (impl. but not incl. in patchset)
  net/rds
6) RDS UDP/DCB transport (not impl. yet)
  net/rds

Does this look right? Right now it sounds like you're saying 1, 5, and
6 go in net/rds, 2-4 go in drivers/infiniband.

I'd personally prefer to not split it up, or to split it on the
natural core/transport boundary, but I can make it work whatever you
decide. :-)

> Furthermore the port you've choosen for the protocol is arbitrary, not
> properly allocated with the appropriate standards committee, and
> therefore could conflict with something other people are using.

I'm sure allocating the port won't be too big an issue.

Regards -- Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html