On Tue, May 26, 2015 at 10:57:18AM -0400, Doug Ledford wrote:
> > Change since v1:
>
> On the face of it, this is a much improved design.
Yes, but again, lets see the actual messages to send for the various
existing kernel use cases.
Jason
--
To unsubscribe from this list: send the line "unsubsc
On Tue, 2015-05-26 at 14:03 +, Wan, Kaike wrote:
> I. Introduction
>
> After posting our design to the mailing list, we received comments concerning
> various aspects of the
> design from Sean Hefty, Ira Weiny, Jason Gunthorpe, and Doug Ledford. Thank
> you all for the help.
>
> The main is
I. Introduction
After posting our design to the mailing list, we received comments concerning
various aspects of the
design from Sean Hefty, Ira Weiny, Jason Gunthorpe, and Doug Ledford. Thank you
all for the help.
The main issues are listed below:
1. Extensibility: the design should be flexibl
> On Thu, May 21, 2015 at 07:52:36AM -0600, Wan, Kaike wrote:
> >
> > The general format of the request and response will be the same:
> >
> > --
> > | netlink header |
> > --
> > | Data header |
> > --
> > | Data |
> >
> > #define IB_NL_DATA_TYPE_INVALID 0x
> > #define IB_NL_DATA_TYPE_NAME0x0001
> > #define IB_NL_DATA_TYPE_ADDRESS_IP 0x0002
> > #define IB_NL_DATA_TYPE_ADDRESS_IP6 0x0003
> > #define IB_NL_DATA_TYPE_PATH_RECORD 0x0004
> > #def
On Thu, May 21, 2015 at 03:44:40PM -0400, ira.weiny wrote:
> The overall message length is in the netlink header. So keeping in mind
> Jasons
> comments regarding returning multiple data records.
There is already an existing idiom and macro set for nesting netlink
records, use it.
Someone need
On Thu, May 21, 2015 at 07:52:36AM -0600, Wan, Kaike wrote:
>
> The general format of the request and response will be the same:
>
> --
> | netlink header |
> --
> | Data header |
> --
> | Data |
> --
>
>
> > The general format of the request and response will be the same:
> >
> > | netlink header |
> > | Data header |
> > | Data |
> >
> > The data header contains information about the type of
> > request/response, the status (for response), the type (format) of the
> > data, the
On Thu, May 21, 2015 at 01:52:36PM +, Wan, Kaike wrote:
>
> In our previous posting to the mailing list, we proposed to send a MAD
> request from kernel (more
> specifically, from ib_sa module) to a user space application (ibacm in this
> case) through netlink.
> The user space application w
> On Thu, 2015-05-21 at 13:21 -0400, Doug Ledford wrote:
>
> The one thing I left out of the above that might be worth changing is the fact
> that you bury your sequence number down in your mad header. If there is a
> generic mechanism that multiple modules can use to send customized data
> via n
> On Thu, 2015-05-21 at 13:52 +, Wan, Kaike wrote:
> > In our previous posting to the mailing list, we proposed to send a MAD
> > request from kernel (more specifically, from ib_sa module) to a user space
> application (ibacm in this case) through netlink.
> > The user space application will s
On Thu, 2015-05-21 at 13:21 -0400, Doug Ledford wrote:
> On Thu, 2015-05-21 at 13:52 +, Wan, Kaike wrote:
> > In our previous posting to the mailing list, we proposed to send a MAD
> > request from kernel (more
> > specifically, from ib_sa module) to a user space application (ibacm in this
>
On Thu, 2015-05-21 at 13:52 +, Wan, Kaike wrote:
> In our previous posting to the mailing list, we proposed to send a MAD
> request from kernel (more
> specifically, from ib_sa module) to a user space application (ibacm in this
> case) through netlink.
> The user space application will send b
In our previous posting to the mailing list, we proposed to send a MAD request
from kernel (more
specifically, from ib_sa module) to a user space application (ibacm in this
case) through netlink.
The user space application will send back the response. This simple scheme can
achieve the goal
of
14 matches
Mail list logo
