> you wrote long emails, I'm asking for one concrete example for that enum
> crunching of adding entries
> not at the end, can you, please?
I've meant e.g. the iscsi tasks in libiscsi.h between 2.6.30 and
2.6.32. But I've meant this for OFED and not the mainline kernel.
2.6.30:
enum {
ISCSI_TASK_COMPLETED,
ISCSI_TASK_PENDING,
ISCSI_TASK_RUNNING,
};
2.6.32:
enum {
ISCSI_TASK_FREE,
ISCSI_TASK_COMPLETED,
ISCSI_TASK_PENDING,
ISCSI_TASK_RUNNING,
ISCSI_TASK_ABRT_TMF, /* aborted due to TMF */
ISCSI_TASK_ABRT_SESS_RECOV, /* aborted due to session recovery */
};
> I want to double check I'm with you - so when you said that iser didn't work
> e.g "TCP worked very well. I've also updated from git to latest 2.0.872
> (latest change 2011-11-01) for testing. TCP always worked and iSER was
> always unusable." you actually wanted to say "iser from ofed" and not iser
> from this or that upstream kernel?
>
I've tried both. The iser from OFED oopsed (because it is 2.6.30 based
- didn't match the 3.0 open-iscsi in-tree) and everything from
upstream kernel 3.0.4 was pretty unstable (mentioned connection aborts
after 5s). And I guess because of the OFED-1.4 user-space from Squeeze
the IB connection was that unstable. The OFED user-space must match
the kernel code of cause. Before I took over the kernel maintaining at
ProfitBricks only few knew about that problem in the company. So, I
thought making everything OFED-1.5.4 is the right approach of doing
that.
>
> as life, mainline isn't perfect, but it doesn't say that ofed is perfect nor
> that by any bit its better then mainline, you may know and if you don't here
> are the news: the ofa community has to decided to stop producing ofed in the
> way it was done over the years, namely from now (Jan 2012) and onward, ofed
> will be only backports provided from mainline, no additions, so this false
> betterness claim can't even be stated anymore. Now, even this "backporting
> only" new mode has to be defined - since for example, is the iscsi case...
> except for iser, ofed will not provide the iscsi modules nor tools, so its
> not clear/how trivial/for someone takes (say) iser from 3.2 and backport it
> to (say) 3.6.35 in manner that it will be operable with 3.6.35 and unknown
> version of the tools.
>
As I wrote, I like that new approach. If OFED-3.2 will match mainline
3.2 this would be great, but then you'll also have to provide the
open-iscsi user-space which you've used for testing in there.
Or/and can't you just provide a list of tools, OFA user-space etc.
which you've tested (e.g. like that BUILD_ID file in OFED)?
I really hope that this makes things better/easier for InfiniBand and
iSER users. I'm looking forward to test that.
My question was more like: "How was it tried to ensure to match kernel
and user-space code right now?" and I did not want to read the
developer's favorite "With the next release everything will be
better." ;-)
Sebastian
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
