Thanks Sean and Roland for your response. You right it's not a primitive in
the IB verbs or iWARP unless you think the verbs define a
non-consuming poll(). Which is a stretch for sure. We fell into the trap
of structuring with it because it was in VAPI and maybe other
that coded over VAPI fell into this deadend too.
I guess you can make arguments that using a peek is sub optimal performance
vise but since there is a peek in sockets and there is a
peek function in VAPI some ULPs may be structures to use it.
Kevin J. Reilly
STSM, HPC Architecture
-Federation/HPS Chief Engineer
-HPC interconnect architect
(office) 845-433-7976 (tieline) 8-293-7976
"Sean Hefty"
<[EMAIL PROTECTED]
.com> To
"'Roland Dreier'"
07/08/2005 06:57 <[EMAIL PROTECTED]>, Kevin
PM Reilly/Poughkeepsie/[EMAIL PROTECTED]
cc
<[email protected]>
Subject
RE: [openib-general] CQ peek
>First, a general point about peek CQ. For all RDMA device
>architectures that I know of, doing "peek CQ" is just as expensive as
>doing "poll CQ," since the driver needs to do the same locking and
>incur the same cache misses either way. And then the app will always
>have to do "poll CQ" later anyway.
{snip}
>This is moderately compelling, and if someone has a concrete use for
>poll CQ I'll probably end up implementing it someday (unless someone
>beats me to it). But I'd be somewhat surprised if a ULP uses a
>primitive that is not defined in either the IB or iWARP verbs.
I vaguely remember discussing peek CQ before, but I don't remember what the
outcome was. I tend to agree with Roland though. There are likely
mechanisms
to perform the same tasks that can provide better performance. I would
lean
more towards removing peek CQ from the API than implementing it, especially
if
it leads an application to be less efficient.
- Sean
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
