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]
Date:   Wed, 8 Feb 2017 00:43:40 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     "Vishwanathapura, Niranjana" <niranjana.vishwanathapura@...el.com>,
        "dledford@...hat.com" <dledford@...hat.com>
CC:     "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "dennis.dalessandro@...el.com" <dennis.dalessandro@...el.com>,
        "ira.weiny@...el.com" <ira.weiny@...el.com>
Subject: RE: [RFC v3 02/11] IB/hfi-vnic: Virtual Network Interface Controller
 (VNIC) interface

Hi 

> -----Original Message-----
> From: linux-rdma-owner@...r.kernel.org [mailto:linux-rdma-
> owner@...r.kernel.org] On Behalf Of Vishwanathapura, Niranjana
> Sent: Tuesday, February 7, 2017 2:23 PM
> To: dledford@...hat.com
> Cc: linux-rdma@...r.kernel.org; netdev@...r.kernel.org;
> dennis.dalessandro@...el.com; ira.weiny@...el.com; Niranjana
> Vishwanathapura <niranjana.vishwanathapura@...el.com>
> Subject: [RFC v3 02/11] IB/hfi-vnic: Virtual Network Interface Controller
> (VNIC) interface
> 
> Add rdma netdev interface to ib device structure allowing rdma netdev
> devices to be allocated by ib clients.
> Define HFI VNIC interface between hardware independent VNIC
> functionality and the hardware dependent VNIC functionality.
> 
> Reviewed-by: Dennis Dalessandro <dennis.dalessandro@...el.com>
> Reviewed-by: Ira Weiny <ira.weiny@...el.com>
> Signed-off-by: Niranjana Vishwanathapura
> <niranjana.vishwanathapura@...el.com>
> ---
>  struct ib_device {
>  	struct device                *dma_device;
> 
> @@ -2096,6 +2114,15 @@ struct ib_device {
>  							   struct
> ib_rwq_ind_table_init_attr *init_attr,
>  							   struct ib_udata
> *udata);
>  	int                        (*destroy_rwq_ind_table)(struct ib_rwq_ind_table
> *wq_ind_table);
> +	/* rdma netdev operations */
> +	struct net_device *(*alloc_rdma_netdev)(
> +					struct ib_device *device,
> +					u8 port_num,
> +					enum rdma_netdev_t type,
> +					const char *name,
> +					unsigned char name_assign_type,
> +					void (*setup)(struct net_device *));
> +	void (*free_rdma_netdev)(struct net_device *netdev);
>  	struct ib_dma_mapping_ops   *dma_ops;
> 
>  	struct module               *owner;

As its clear from the cover letter and from the request to place this in drivers/infiniband/ulp,
Instead of increasing the ib_dev structure further,
Can you change the code to make use of ib_register_client() and friend functions to register vnic as ULP.
(similar to other ULP such as uverbs, srp, ipoib).
This will also allow you get to get notified for removing the vnic device when underlying rdma device gets removed.
Based on the property that gets exposed by the ibdev, vnic driver filters whether it needs to load its vnic to specific device or not.
This way modules are isolated between core and ULP little better.
Would it work for you?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ