So what you are proposing is that Listener will specify IETF port (2
bytes).
CM will generate an IB SID to listen on. That SID will have wildcarding
for 24 bits.
The requestor will specify: version, IP version, SRC port and DST port.
Based on that CM will generate the SID to send request to.
It wil
Kanevsky, Arkady wrote:
So what you are proposing is that Listener will specify IETF port (2
bytes).
CM will generate an IB SID to listen on. That SID will have wildcarding
for 24 bits.
The requestor will specify: version, IP version, SRC port and DST port.
Based on that CM will generate the SID
Sean Hefty wrote in response to Arkady Kanevsky:
>
> What's this proposal defines is basically a 65th bit for the
> service ID. If the new 65 bit SID is:
>
> 1 - private data has this format
> 0 - private data format is unknown
>
> Why do we need this 65th bit?
>
Because current software
Caitlin Bestler wrote:
Because current software can set any of the 64 bits.
There is no assurance that any bit within the current 64
being set means that privileged software on the remote
side is vouching for the standardized portion of the
private data.
The current software did not require cha
Sean> The current software did not require changes to the CM
Sean> protocol, and does provide assurance that the private data
Sean> was formatted by a kernel entity.
How do you prevent a userspace process from using the current ucm
module to connect to one of the CMA services on a remo
Roland Dreier wrote:
Sean> The current software did not require changes to the CM
Sean> protocol, and does provide assurance that the private data
Sean> was formatted by a kernel entity.
How do you prevent a userspace process from using the current ucm
module to connect to one of the
Roland Dreier wrote:
> Sean> The current software did not require changes to the CM
> Sean> protocol, and does provide assurance that the private data
> Sean> was formatted by a kernel entity.
>
> How do you prevent a userspace process from using the current
> ucm module to connect to
The CM cannot get a message from a non-priviliged requestor, because a non-privilited requestor cannot insert the priviliged Q_Key into the packet.
Renato J Recio
Chief Architect, eServer I/O
IBM Distinguished Engineer
Member IBM Academy of Technology
Tel 512-838-3685, T/L 678-3685
">"Caitlin Be
From: Renato Recio [mailto:[EMAIL PROTECTED]
Sent: Friday, November 11, 2005 11:01 AMTo: Caitlin
BestlerCc: Kanevsky, Arkady; [EMAIL PROTECTED]; Sean
Hefty; openib-general@openib.org; [EMAIL PROTECTED]Subject: Re:
[swg] RE: [openib-general] RE: [dat-discussions] socket bas
At 10:28 AM 11/9/2005, Rick Frank wrote:
Yes, the application is responsible for detecting lost msgs at the
application level - the transport can not do this.
RDS does not guarantee that a message
has been delivered to the application - just that once the transport has
accepted a msg it will d
> From: Caitlin Bestler [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 11, 2005 9:57 AM
>
> Sean Hefty wrote in response to Arkady Kanevsky:
>
> > What's this proposal defines is basically a 65th bit for the
> > service ID. If the new 65 bit SID is:
> >
> > 1 - private data has this
Any active side QP can target a passive side CM QP (QP1 or redirected QPN). However, due to the use of priviliged Q_Keys, only an active side priviliged QP can target the passive side CM QP.
It seems to me that our proposal of having the Service ID be generated by priviliged mode code, having
Michael Krause wrote:
At 10:28 AM 11/9/2005, Rick Frank wrote:
Yes, the application is responsible for detecting lost msgs at the
application level - the transport can not do this.
RDS does not guarantee that a message has been delivered to the
application - just that once the transport has
On 11/11/05, Michael Krause <[EMAIL PROTECTED]> wrote:
> Please clarify the following which was in the document provided by Oracle.
>
> On page 3 of the RDS document, under the section "RDP Interface", the 2nd
> and 3rd paragraphs are state:
>
>* RDP does not guarantee that a datagram is delive
From: Renato Recio [mailto:[EMAIL PROTECTED]
Sent: Friday, November 11, 2005 12:25 PMTo: Caitlin
BestlerCc: Kanevsky, Arkady; [EMAIL PROTECTED]; Sean
Hefty; openib-general@openib.org; [EMAIL PROTECTED]Subject: RE:
[swg] RE: [openib-general] RE: [dat-discussions] socket bas
> From: Caitlin Bestler [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 11, 2005 1:12 PM
>
> How does this prevent a non-privileged client running on a remote host with
> current
> CM software from generating a connection request to the targeted Service ID
> with the entire private data coming
Fab Tillier wrote:
>> From: Caitlin Bestler [mailto:[EMAIL PROTECTED]
>> Sent: Friday, November 11, 2005 1:12 PM
>>
>> How does this prevent a non-privileged client running on a remote
>> host with current CM software from generating a connection request
>> to the targeted Service ID with the enti
> From: Caitlin Bestler [mailto:[EMAIL PROTECTED]
>
> Fab Tillier wrote:
> >> From: Caitlin Bestler [mailto:[EMAIL PROTECTED]
> >> Sent: Friday, November 11, 2005 1:12 PM
> >>
> >> How does this prevent a non-privileged client running on a remote
> >> host with current CM software from generating
At 01:01 PM 11/11/2005, Nitin Hande wrote:
Michael Krause wrote:
At 10:28 AM 11/9/2005, Rick
Frank wrote:
Yes, the application is
responsible for detecting lost msgs at the application level - the
transport can not do this.
RDS does not guarantee that a message has been delivered to the
applica
At 01:02 PM 11/11/2005, Ranjit Pandit wrote:
On 11/11/05, Michael Krause
<[EMAIL PROTECTED]> wrote:
> Please clarify the following which was in the document provided by
Oracle.
>
> On page 3 of the RDS document, under the section "RDP
Interface", the 2nd
> and 3rd paragraphs are state:
>
> * R
A current passive side CM will reject the incoming CM REQ, because the Service ID will not be recognized.
Renato J Recio
Chief Architect, eServer I/O
IBM Distinguished Engineer
Member IBM Academy of Technology
Tel 512-838-3685, T/L 678-3685
">"Caitlin Bestler" <[EMAIL PROTECTED]>
"Cait
21 matches
Mail list logo
