On Thu, 2006-01-19 at 13:29 -0700, Eric W. Biederman wrote:
> Agreed. Part of the problem is the IB layer is insufficient, or
> at least you perceive it that way. At that level if you can express
> your problems we can get the IB layer fixed.
Our low-level driver is not IB, doesn't implement IB, and doesn't care
about IB. Our upper-level driver implements IB, and interfaces to the
existing IB tree.
> Except not being a member of the IB verbs camp there is nothing
> your hardware does that is exotic enough for the IB layer to
> fall down.
We implement IB verbs just fine, both in the kernel and userspace.
> 1) The IB stack poorly supports your driver.
> - IB stack problem. If you could help point out what
> is wrong with the IB stack that would be great.
I have no issue with it. We already act as a provider to it, in our
higher-layer driver code.
We have some user page pinning code that is clearly similar in purpose,
and that I want to refactor in a helpful way.
We have UD and RC protocol engines that could profitably be moved out of
our driver and into the IB layer at some future point in time, should
some other device ever come along that could use them.
> For those who need the buzz words to understand what is going
> on the ipath hardware largely does stateless offload for IB while
> the mellanox hardware does whole protocol offload.
Our hardware actually does no offload whatsoever. That's why we are (a)
fast (b) flexible and (c) somewhat big and unusual compared to other IB
drivers.
<b
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
