netdev - Re: [PATCH v3 00/16] add Intel X722 iWARP driver

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: <20160121182420.GA51708@flatif-MOBL1>
Date:	Thu, 21 Jan 2016 12:24:20 -0600
From:	Faisal Latif <faisal.latif@...el.com>
To:	Or Gerlitz <ogerlitz@...lanox.com>
Cc:	Steve Wise <swise@...ngridcomputing.com>,
	'Or Gerlitz' <gerlitz.or@...il.com>,
	'Doug Ledford' <dledford@...hat.com>,
	linux-rdma@...r.kernel.org,
	'Linux Netdev List' <netdev@...r.kernel.org>,
	'Jeff Kirsher' <jeffrey.t.kirsher@...el.com>,
	e1000-rdma@...ts.sourceforge.net
Subject: Re: [PATCH v3 00/16] add Intel X722 iWARP driver

On Thu, Jan 21, 2016 at 07:05:48PM +0200, Or Gerlitz wrote:
> On 1/21/2016 5:32 PM, Steve Wise wrote:
> >Only a single user-space daemon is used.
> 
> Good.
> 
> >Someone from Intel might have insight into the architecture and design.  Perhaps the intention is that individual drivers might want to have their own handlers for these various operations.  But currently they all use the core/common ones.
> 
> But if there's single daemon there and one set of pre-defined  callbacks,
> why different netlink commands are needed? in what case the damon uses
> RDMA_NL_NES or RDMA_NL_C4IW or the new define and why?
> 
> Or.

The Intel X722 iWARP driver implements the port mapper interface as is in the current kernel, utilizing iwpm.

The portmapper daemon sends netlink messages to the client drivers (nes, cxgb4) and RDMA_NL_NES/RDMA_NL_C4IW
enums are part of the netlink message header used by the netlink protocol to deliver the messages to the
corresponding client.

We can certainly take up the discussion on improving the current port mapper design/implementation. But
that would be more appropriate in a separate thread.

Thanks
Faisal