On 12/2/2011 2:04 AM, Hefty, Sean wrote:
We propose a new process for the OFED releases starting from next OFED release:
- OFED content will be the relevant kernel.org modules and user space released
packages
- OFED will offer only backports to the distros (no fixes)
I think this point needs to be clarified
Sean, Yes, I agree, we have to be precise here, the term back-porting
has to be made clear:
The kernel is a large piece that keeps moving on - its made of many
smaller pieces/components, but with very sharp and well defined
dependencies and interactions. The rdma stack is far from being an
isolated piece which you can pull from kernel X and plug into kernel Y -
this applies all over the place in varying extents - e.g from the RDMA
HW drivers, through the IB core and up to the ULPs.
The latter is the easiest to explain, as Roland once commented, each IB
ULP driver is a fish and a eel - so SRP/iSER/rNFS/IPoIB are all IB
fishes working with the IB core services and with the HW through the
verbs, but the are part from higher-level constructs in the kernel, such
as being network device (IPoIB), SCSI Low Level drivers (1st two), iscsi
transport provider (iser) and RPC provider (rNFS). Now, BACKPORTING
these stacks (SCSI, iSCSI, RPC/NFS, etc) isn't something that OFA can
carry, and it would be self-damaging to create notion with end-users
that OFED does so. I tend to think this is done now for rNFS, and its a
mistake. Distributions do that, by the way, but its part of their bread
and butter.
This argument applies also to the core, yes. The core and IPoIB has
interactions with the networking stack, e.g around route and neighbour
lookups, and alike. The networking stack is something that sits deeply
into the built in part of the kernel and changes every now and then.
BACKPORTING here would mean to simply remove sets of patches from the
core and ipoib.
In the HW drivers space, things could be simpler, but I haven't thought
about it deeply, though.
To be concrete/constructive here, a per IB stack module individual has
to be assigned for that backporting, which doesn't mean "make IB code
from kernel X to build under kernel Y" - lets
see if we have people to actually do that.
For example, on the iser space, and for the stack provided by Mellanox
to customers - I took the approach of iser_backport(X,Y) = ~Y --- which
means that if I have to backport the iser code from kernel X into kernel
Y, I simply use the iser code that comes with Y
I do that since Y has well/tight integrated iscsi stack for which the
maintainers worked very hard to produce, and I can't re-invent
backporting that stack.
The tilde in ~Y stands for slight verb changes that could arise from the
backporting the rest of the IB stack has gone through, from X to Y, so
if the verb to create CQ has another param in X vs what it had in Y- I
add it under the ~ umbrella, is that clear?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
