[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <552F651A.8040708@profitbricks.com>
Date: Thu, 16 Apr 2015 09:30:34 +0200
From: Michael Wang <yun.wang@...fitbricks.com>
To: Hal Rosenstock <hal@....mellanox.co.il>
CC: Roland Dreier <roland@...nel.org>,
Sean Hefty <sean.hefty@...el.com>,
Hal Rosenstock <hal.rosenstock@...il.com>,
linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org,
Tom Tucker <tom@...ngridcomputing.com>,
Steve Wise <swise@...ngridcomputing.com>,
Hoang-Nam Nguyen <hnguyen@...ibm.com>,
Christoph Raisch <raisch@...ibm.com>,
Mike Marciniszyn <infinipath@...el.com>,
Eli Cohen <eli@...lanox.com>,
Faisal Latif <faisal.latif@...el.com>,
Jack Morgenstein <jackm@....mellanox.co.il>,
Or Gerlitz <ogerlitz@...lanox.com>,
Haggai Eran <haggaie@...lanox.com>,
Ira Weiny <ira.weiny@...el.com>, Tom Talpey <tom@...pey.com>,
Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
Doug Ledford <dledford@...hat.com>
Subject: Re: [PATCH v3 01/28] IB/Verbs: Implement new callback query_transport()
Hi, Hal
On 04/15/2015 08:36 PM, Hal Rosenstock wrote:
> On 4/13/2015 8:22 AM, Michael Wang wrote:
[snip]
>> __attribute_const__ enum rdma_transport_type
>> @@ -1501,6 +1504,8 @@ struct ib_device {
>> int (*query_port)(struct ib_device *device,
>> u8 port_num,
>> struct ib_port_attr *port_attr);
>> + enum rdma_transport_type (*query_transport)(struct ib_device *device,
>> + u8 port_num);
>> enum rdma_link_layer (*get_link_layer)(struct ib_device *device,
>> u8 port_num);
>> int (*query_gid)(struct ib_device *device,
>
> libibverbs also exposes transport at the device level. Isn't a change to
> make transport per port rather than per device needed there as well to
> be consistent with these proposed kernel changes ? If so, would the
> additional IBoE transport be exposed ? We also need to worry about
> backward compatibility for existing applications.
The proposal of this patch-set is to integrate IB core layer management
checking, without noticed by user layer.
Later the bitmask reform should not be noticed by core layer, so user
layer app should have totally no idea what happened inside kernel ;-)
Regards,
Michael Wang
>
> -- Hal
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists