On Thu, 2006-02-09 at 19:02, Sean Hefty wrote:
Does anything outside of userspace send a multi-segment RMPP MAD? Is it
likely
that a kernel component would need to ?
The only case I can think of here is a SA GetMultiPath for any kernel
components as GetMulti is two sided but the kernel
On Sat, 2006-02-11 at 07:39, Hal Rosenstock wrote:
On Thu, 2006-02-09 at 19:02, Sean Hefty wrote:
Does anything outside of userspace send a multi-segment RMPP MAD? Is it
likely
that a kernel component would need to ?
The only case I can think of here is a SA GetMultiPath for any
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Subject: Re: FW: [PATCH 1 of 3] mad: large RMPP support
Roland Dreier wrote:
My rule of thumb is that we shouldn't rely on being able to allocate a
contiguous buffer bigger than 4 KB, but assuming we can allocate 4 KB
is fine. 4 KB is the lowest
Michael S. Tsirkin wrote:
Given that the last segment has a different size, it seems cleaner
to just keep the segment size part of ib_mad_segment structure.
The last segment should provide any necessary padding, so that the resulting MAD
is 256-bytes. Segments 2 through n should be the same
Sean, at least I am a bit confused at this point. Let's go back and
summarize the list of issues you see with the last patchset, OK?
As far as I can see, we decided that the list of segments is the right approach.
It also seems you are also inclining towards uniform handling of the first
segment
Michael S. Tsirkin wrote:
As far as I can see, we decided that the list of segments is the right approach.
Agreed.
It also seems you are also inclining towards uniform handling of the first
segment and the rest of them, so I hope this means the simplification
achieved by always using an s/g
Michael S. Tsirkin wrote:
The last segment should provide any necessary padding, so that the
resulting MAD is 256-bytes. Segments 2 through n should be the same size.
Uh, right. So segment size could just be a define.
To be clear, the segment size still varies by class, but would be
Sean The problem is that it results in walking the list every
Sean time the user wants to see the next segment. This is an
Sean O(n^2) operation. In any case I can think of, all that's
Sean needed is a single walk through the list to copy the
Sean userspace MAD data into the
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Externally, a user should have access to the segment list
directly, rather than through a function call.
Why not a function call?
The latest idea that I was suggesting was to separate the MAD header from
the data segments for multi-segment/RMPP
Quoting r. Roland Dreier [EMAIL PROTECTED]:
If we want to keep the internals hidden, then we could expose some
sort of iterator object that clients can use to walk the list in O(n).
AFAIK thats what Jack is working on. Expect results by Monday.
--
Michael S. Tsirkin
Staff Engineer, Mellanox
If we want to keep the internals hidden, then we could expose some
sort of iterator object that clients can use to walk the list in O(n).
AFAIK thats what Jack is working on. Expect results by Monday.
Why not just use the list functionality that ships with the kernel? This is
what the
The latest idea that I was suggesting was to separate the MAD header from
the data segments for multi-segment/RMPP active MADs. Let *mad reference
the header, and rmpp_list reference all data segments. Non-RMPP MADs would
use *mad to reference the entire buffer. For an RMPP MAD (one with
12 matches
Mail list logo
