On 27/06/2013 14:46, Or Gerlitz wrote:
On 26/06/2013 11:15, Nicholas A. Bellinger wrote:
Hi Or & Co,
Ok, sendtargets discovery is now functioning over iser. The updated
target patches + v2 changelogs are in for-next commits here:
http://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.
On 26/06/2013 11:15, Nicholas A. Bellinger wrote:
Hi Or & Co,
Ok, sendtargets discovery is now functioning over iser. The updated
target patches + v2 changelogs are in for-next commits here:
http://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?h=for-next&id=889c8a68b8483a
On 06/27/2013 04:12 AM, Or Gerlitz wrote:
> On 27/06/2013 01:09, Mike Christie wrote:
>>> Mike, sorry I am not near plain git now, but if I look through the
>>> > kernel.org git web on Linus tree I see ISCSI_FLASHNODE_DISCOVERY_SESS
>>> > defined in include/scsi/iscsi_if.h but not ISCSI_PARAM_DISCO
On 27/06/2013 01:09, Mike Christie wrote:
Mike, sorry I am not near plain git now, but if I look through the
>kernel.org git web on Linus tree I see ISCSI_FLASHNODE_DISCOVERY_SESS
>defined in include/scsi/iscsi_if.h but not ISCSI_PARAM_DISCOVERY_SESS
>- am I still missing that? its
My mistake. I
-Original Message-
From: Or Gerlitz
Reply-To: "open-iscsi@googlegroups.com"
Date: Thursday 27 June 2013 2:25 AM
To: "open-iscsi@googlegroups.com"
Cc: Or Gerlitz , "Nicholas A. Bellinger"
, Alexander Nezhinsky
Subject: Re: do discovery through SW transpo
On 06/26/2013 03:55 PM, Or Gerlitz wrote:
> On Wed, Jun 26, 2013 at 7:29 PM, Mike Christie wrote:
>>
>> On 06/26/2013 11:25 AM, Mike Christie wrote:
>>
Mike, I don't see a sign for ISCSI_PARAM_DISCOVERY_SESS in the upstream
open-iscsi user or kernel code nor in the upstream kernel..
On Wed, Jun 26, 2013 at 7:29 PM, Mike Christie wrote:
>
> On 06/26/2013 11:25 AM, Mike Christie wrote:
>
> >>
> >> Mike, I don't see a sign for ISCSI_PARAM_DISCOVERY_SESS in the upstream
> >> open-iscsi user or kernel code nor in the upstream kernel... but I
> >
> > Check Linus's tree or James sc
On 06/26/2013 11:25 AM, Mike Christie wrote:
>>
>> Mike, I don't see a sign for ISCSI_PARAM_DISCOVERY_SESS in the upstream
>> open-iscsi user or kernel code nor in the upstream kernel... but I
>
> Check Linus's tree or James scsi misc branch. I pulled today and see it
> in both.
It is git commi
On 06/26/2013 10:47 AM, Or Gerlitz wrote:
> On 20/06/2013 19:28, Mike Christie wrote:
>> On 06/20/2013 11:10 AM, Or Gerlitz wrote:
>>> On 19/06/2013 00:47, Mike Christie wrote:
On 06/18/2013 10:35 AM, Or Gerlitz wrote:
> Now, back to the initiator, Mike, is there a chance that the initiato
On 26/06/2013 11:15, Nicholas A. Bellinger wrote:
On Sun, 2013-06-23 at 17:47 +0300, Or Gerlitz wrote:
On 23/06/2013 17:40, Or Gerlitz wrote:
there you go, here's the output
isert_cma_handler: event 4 status 0 conn 88011a55d600 id
8801085c5400
RDMA_CM_EVENT_CONNECT_REQUEST: >>
On 20/06/2013 19:28, Mike Christie wrote:
On 06/20/2013 11:10 AM, Or Gerlitz wrote:
On 19/06/2013 00:47, Mike Christie wrote:
On 06/18/2013 10:35 AM, Or Gerlitz wrote:
Now, back to the initiator, Mike, is there a chance that the initiator
SENDS the key TargetRecvDataSegmentLength? this shouldn
On 26/06/2013 11:15, Nicholas A. Bellinger wrote:
Hi Or & Co,
Ok, sendtargets discovery is now functioning over iser.
forgot to say: cool! thanks for the hard work get that done.
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe fr
On Sun, 2013-06-23 at 17:47 +0300, Or Gerlitz wrote:
> On 23/06/2013 17:40, Or Gerlitz wrote:
> >
> >
> > there you go, here's the output
> >
> > isert_cma_handler: event 4 status 0 conn 88011a55d600 id
> > 8801085c5400
> > RDMA_CM_EVENT_CONNECT_REQUEST: >>>
> > Entering isert_
On 23/06/2013 17:40, Or Gerlitz wrote:
there you go, here's the output
isert_cma_handler: event 4 status 0 conn 88011a55d600 id
8801085c5400
RDMA_CM_EVENT_CONNECT_REQUEST: >>>
Entering isert_connect_request cma_id: 8801085c5400, context:
88011a55d600
Using respo
On 20/06/2013 23:31, Nicholas A. Bellinger wrote:
On Thu, 2013-06-20 at 19:01 +0300, Or Gerlitz wrote:
On 19/06/2013 04:32, Nicholas A. Bellinger wrote:
So I'm pretty sure this is due to iscsi_target_parameters.c:
iscsi_set_keys_irrelevant_for_discovery() currently clearing
INITIATORRECVDATASEG
On Thu, Jun 20, 2013 at 11:31 PM, Nicholas A. Bellinger wrote:
> On Thu, 2013-06-20 at 19:01 +0300, Or Gerlitz wrote:
> > On 19/06/2013 04:32, Nicholas A. Bellinger wrote:
> > > So I'm pretty sure this is due to iscsi_target_parameters.c:
> > > iscsi_set_keys_irrelevant_for_discovery() currently
On Thu, 2013-06-20 at 19:01 +0300, Or Gerlitz wrote:
> On 19/06/2013 04:32, Nicholas A. Bellinger wrote:
> > So I'm pretty sure this is due to iscsi_target_parameters.c:
> > iscsi_set_keys_irrelevant_for_discovery() currently clearing
> > INITIATORRECVDATASEGMENTLENGTH and TARGETRECVDATASEGMENTLENG
On 06/20/2013 11:10 AM, Or Gerlitz wrote:
> On 19/06/2013 00:47, Mike Christie wrote:
>> On 06/18/2013 10:35 AM, Or Gerlitz wrote:
>>> Now, back to the initiator, Mike, is there a chance that the initiator
>>> SENDS the key TargetRecvDataSegmentLength? this shouldn't be the case
>>> according to th
On 19/06/2013 00:47, Mike Christie wrote:
On 06/18/2013 10:35 AM, Or Gerlitz wrote:
Now, back to the initiator, Mike, is there a chance that the initiator
SENDS the key TargetRecvDataSegmentLength? this shouldn't be the case
according to the iser IETF spec.
See add_params_transport_specific()
On 19/06/2013 04:32, Nicholas A. Bellinger wrote:
So I'm pretty sure this is due to iscsi_target_parameters.c:
iscsi_set_keys_irrelevant_for_discovery() currently clearing
INITIATORRECVDATASEGMENTLENGTH and TARGETRECVDATASEGMENTLENGTH for
all discovery scenarios..
As I'm still not yet able to fo
On Tue, 2013-06-18 at 18:35 +0300, Or Gerlitz wrote:
> On 15/06/2013 11:25, Nicholas A. Bellinger wrote:
> > Hi Or & Mike,
> >
> > On Tue, 2013-06-11 at 08:04 +0300, Or Gerlitz wrote:
> >> On 06/06/2013 18:01, Mike Christie wrote:
> >>> However, above I am not talking about that or doing discovery
On 06/18/2013 10:35 AM, Or Gerlitz wrote:
>
> Now, back to the initiator, Mike, is there a chance that the initiator
> SENDS the key TargetRecvDataSegmentLength? this shouldn't be the case
> according to the iser IETF spec.
>
See add_params_transport_specific() in login.c. Add some prints in the
On 15/06/2013 11:25, Nicholas A. Bellinger wrote:
Hi Or & Mike,
On Tue, 2013-06-11 at 08:04 +0300, Or Gerlitz wrote:
On 06/06/2013 18:01, Mike Christie wrote:
However, above I am not talking about that or doing discovery over a
normal session in general. I was just trying to get clarification
On 15/06/2013 11:29, Nicholas A. Bellinger wrote:
Hi Or & Mike,
On Tue, 2013-06-11 at 08:04 +0300, Or Gerlitz wrote:
On 06/06/2013 18:01, Mike Christie wrote:
However, above I am not talking about that or doing discovery over a
normal session in general. I was just trying to get clarification
On 12/06/2013 10:53, Ulrich Windl wrote:
are you sure you installed the static C libraries?
this might be the problem, I wasn't sure what rpm/s I need to install
for that.
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from th
Hi!
I wonder: Isn't "-static" quite obsolete? If not, are you sure you installed
the static C libraries?
Regards,
Ulrich
>>> Or Gerlitz schrieb am 12.06.2013 um 09:31 in
>>> Nachricht
<51b823e6.5090...@mellanox.com>:
> On 11/06/2013 20:18, Mike Christie wrote:
>> On 6/9/13 9:54 AM, Or Gerlitz
On 11/06/2013 20:18, Mike Christie wrote:
On 6/9/13 9:54 AM, Or Gerlitz wrote:
usr]# make
Hey,
Did you figure this out?
Support for that changed. You need to do make from the top level dir,
because of dependencies on other stuff. Once that stuff is built you
can do make from the usr dir t
Hi Mike,
There are iser environments where we might need to do iscsi discovery
over rdma connection, that is establish iser connection and then carry
the discovery session over it. I was a bit away for the developments in
the initiator over the last months so would need some crash help here.
On 06/06/2013 18:01, Mike Christie wrote:
I think everything should be there. I thought I worked on iser when
doing the work too. You need the attached kernel patch.
In the other mails I think I said you need a change to the userspace
iser code, but ignore that. In the common iscsi code I did a
On 06/06/2013 18:01, Mike Christie wrote:
However, above I am not talking about that or doing discovery over a
normal session in general. I was just trying to get clarification for
what you wanted. I was not sure if there was some new iser spec stuff
that I missed and you wanted to implement.
H
On 6/9/13 9:54 AM, Or Gerlitz wrote:
usr]# make
Hey,
Did you figure this out?
Support for that changed. You need to do make from the top level dir,
because of dependencies on other stuff. Once that stuff is built you can
do make from the usr dir to build just the usr stuff.
--
You receiv
On Thu, Jun 6, 2013 at 6:01 PM, Mike Christie wrote:
> On 06/06/2013 01:28 AM, Or Gerlitz wrote:
> I think everything should be there. I thought I worked on iser when
> doing the work too. You need the attached kernel patch.
> In the other mails I think I said you need a change to the userspace
>
On 06/06/2013 01:28 AM, Or Gerlitz wrote:
> On Thu, Jun 6, 2013 at 2:22 AM, Mike Christie wrote:
>> On 06/05/2013 03:36 PM, Or Gerlitz wrote:
>
>>> 1. we don't want to offload the sendtargets based discovery but rather
>>> to conduct it over an iser IB/RoCE connection and not TCP connection
>
>>
On Thu, Jun 6, 2013 at 2:22 AM, Mike Christie wrote:
> On 06/05/2013 03:36 PM, Or Gerlitz wrote:
>> 1. we don't want to offload the sendtargets based discovery but rather
>> to conduct it over an iser IB/RoCE connection and not TCP connection
> One other question/clarification. You do discovery
On Thu, Jun 6, 2013 at 2:16 AM, Mike Christie wrote:
> On 06/05/2013 03:36 PM, Or Gerlitz wrote:
>> Mike Christie wrote:
>>
>> Mike,
>>
>> Thanks for clarifying things out here,
>>
>>> calls the transport template ep_connect/poll/disconnect and send_pdu calls
>>> likes is
>>> done for normal ses
On 06/05/2013 03:36 PM, Or Gerlitz wrote:
> I need some clarifications, if user space does send pdu and we have
> mechanisms in place
> to delivered a pdu received by the kernel to user space. Then from the
> iser kernel transport view point running a discovery session is an
> iscsi/iser session wi
On 06/05/2013 03:36 PM, Or Gerlitz wrote:
> Mike Christie wrote:
>
> Mike,
>
> Thanks for clarifying things out here,
>
>> calls the transport template ep_connect/poll/disconnect and send_pdu calls
>> likes is
>> done for normal session login. That code then will do discovery through that
>> c
Mike Christie wrote:
Mike,
Thanks for clarifying things out here,
> calls the transport template ep_connect/poll/disconnect and send_pdu calls
> likes is
> done for normal session login. That code then will do discovery through that
> connection. To use this the driver only needs to set CAP_TE
On 06/05/2013 11:35 AM, Or Gerlitz wrote:
> Hi Mike,
>
> There are iser environments where we might need to do iscsi discovery
> over rdma connection, that is establish iser connection and then carry
> the discovery session over it. I was a bit away for the developments in
> the initiator over the
39 matches
Mail list logo
