On Mon, Feb 23, 2015 at 5:25 AM, Mike Christie wrote:
> Dropping lsf for iscsi list.
>
>
> Sorry about that. I thought I sent this to you. It must have got lost.
> Attached is the kernel changes for session based mq support (patch made
> over linus's tree). It just has the core changes only. I di
On 1/24/2015 6:54 PM, Or Gerlitz wrote:
On Fri, Jan 23, 2015 at 10:15 PM, Mike Christie <mailto:micha...@cs.wisc.edu>>wrote:
On 01/23/2015 01:20 AM, Or Gerlitz wrote:
> I don't think we need to go for so many changes in libiscsi and such
> just for that. But l
On Fri, Jan 23, 2015 at 10:15 PM, Mike Christie
wrote:
> On 01/23/2015 01:20 AM, Or Gerlitz wrote:
> > I don't think we need to go for so many changes in libiscsi and such
> > just for that. But let us 1st understand what exactly is sent to the
> > target as MRDSL in
On Fri, Jan 23, 2015 at 12:45 AM, Mike Christie
wrote:
> On 1/22/15, 12:03 PM, Sagi Grimberg wrote:
>
>> On 1/22/2015 3:53 PM, Or Gerlitz wrote:
>>
>>> On 1/22/2015 1:10 AM, Mike Christie wrote:
>>>
>>>> On 01/21/2015 03:14 PM, Or Gerlitz wrote:
On 1/22/2015 1:10 AM, Mike Christie wrote:
On 01/21/2015 03:14 PM, Or Gerlitz wrote:
On Wed, Jan 21, 2015 at 8:41 PM, Mike Christie mailto:micha...@cs.wisc.edu>> wrote:
On 1/21/15, 8:19 AM, Or Gerlitz wrote:
Hi Mike,
Long time.. hope you are all well after EOY ho
On Wed, Jan 21, 2015 at 8:41 PM, Mike Christie wrote:
> On 1/21/15, 8:19 AM, Or Gerlitz wrote:
>
>> Hi Mike,
>>
>> Long time.. hope you are all well after EOY holidays and with energy to
>> for the MCS debates @ LSF...
>>
>>
> Hey,
>
> Hope you
Hi Mike,
Long time.. hope you are all well after EOY holidays and with energy to
for the MCS debates @ LSF...
So back in upstream commit ea05be3ff043efd44256283d968fa1bb9a371568
"iscsi tools: set non negotiated params early" we are
doing set_param towards the kernel/transport before sending t
Hi Mike,
Long time.. hope you are all well after EOY holidays and with energy to
for the MCS debates @ LSF...
So back in upstream commit ea05be3ff043efd44256283d968fa1bb9a371568
"iscsi tools: set non negotiated params early" we are
doing set_param towards the kernel/transport before sending t
On 10/17/2014 02:05 AM, Moussa Ba wrote:
On Thursday, October 16, 2014 4:01:49 PM UTC-7, Or Gerlitz wrote:
On 10/16/2014 09:14 PM, Moussa Ba wrote:
> FYI the system is a supermicro based system with integrated
ConnextX3
> card running 2.30firmware info is below (ob
On 10/16/2014 09:14 PM, Moussa Ba wrote:
FYI the system is a supermicro based system with integrated ConnextX3
card running 2.30firmware info is below (obtained when installing
mlnx-en-2.3.1.0.0 from Mellanox website).
oops, you can't mix two driver (mlx4_core and mlx4_en) from an overlay
On 10/16/2014 08:55 PM, Moussa Ba wrote:
can ping the address, it seems to be going through the correct device.
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface
0.0.0.0 10.102.40.1 0.0.0.0 UG1024 0
0 enp2s0f
On 10/16/2014 08:44 PM, Moussa Ba wrote:
Here is the dmesg from ib_iser debug_level=2 while doing a discovery
via iser.
[512042.466216] iscsi: registered transport (iser)
[512140.195141] iser: iser_connect:connecting to: 192.168.111.100,
port 0xbd0c
[512140.195896] iser: iser_cma_handler:even
On 10/16/2014 02:30 AM, Mike Christie wrote:
On 10/14/2014 01:50 PM, Moussa Ba wrote:
iscsiadm: iscsi_create_leading_conn discovery ep connect
iscsiadm: in ktransport_ep_connect
iscsiadm: in __kipc_call
iscsiadm: in kwritev
iscsiadm: in nlpayload_read
iscsiadm: in nlpayload_read
iscsiadm: ktra
On 10/14/2014 5:22 AM, Mike Christie wrote:
On 10/13/2014 10:04 PM, Mike Christie wrote:
On 10/13/2014 03:49 PM, Moussa Ba wrote:
I am confusedIs there new code for me to try? Trying to do a
No.
discovery after updating the interface using iser results in a :
*iscsiadm: Connection to d
On 06/03/2014 20:01, Mike Christie wrote:
On 02/27/2014 04:20 PM, Or Gerlitz wrote:
Hi Mike,
We're working now on sort of house cleaning w.r.t the iser transport
code that deals with connections tear-down and resources cleanups.
Examining the iscsi state machine ladder diagram for conne
On 07/04/2014 19:34, Mike Christie wrote:
On 04/06/2014 01:03 PM, Or Gerlitz wrote:
On Sun, Apr 6, 2014, Michael Christie wrote:
On Apr 6, 2014, Or Gerlitz wrote:
the kernel code path of iscsi_complete_pdu--> __iscsi_complete_pdu -->
iscsi_scsi_cmd_rsp
uses a "datalen" va
On Sun, Apr 6, 2014, Michael Christie wrote:
> On Apr 6, 2014, Or Gerlitz wrote:
> > the kernel code path of iscsi_complete_pdu--> __iscsi_complete_pdu -->
> > iscsi_scsi_cmd_rsp
> > uses a "datalen" value which should account for the length of t
Hi Mike,
the kernel code path of iscsi_complete_pdu--> __iscsi_complete_pdu -->
iscsi_scsi_cmd_rsp
uses a "datalen" value which should account for the length of the data
received from the target.
In iser/iscsi_iser_recv() we don't skip the AHS in case the target sent
it and I'd like to fix
On 06/03/2014 20:01, Mike Christie wrote:
On 02/27/2014 04:20 PM, Or Gerlitz wrote:
Hi Mike,
We're working now on sort of house cleaning w.r.t the iser transport
code that deals with connections tear-down and resources cleanups.
Examining the iscsi state machine ladder diagram for conne
On Fri, Feb 28, 2014 at 12:20 AM, Or Gerlitz wrote:
> Hi Mike,
>
> We're working now on sort of house cleaning w.r.t the iser transport
> code that deals with connections tear-down and resources cleanups.
> Examining the iscsi state machine ladder diagram for connection
>
Hi Mike,
We're working now on sort of house cleaning w.r.t the iser transport
code that deals with connections tear-down and resources cleanups.
Examining the iscsi state machine ladder diagram for connection
establishment and login which goes like:
01 transport end-point (create and) connect
02
On 04/02/2014 20:34, Mike Christie wrote:
This patch has iscsid/iscsiadm pass the non-negotiated settings (abort
tmo, persistent ip, target name, chap, etc) before we send the iscsi
login pdu. This fixes a issue where when login takes a long time and you
run iscsiadm -m session you get errors due
On 02/02/2014 09:34, Or Gerlitz wrote:
On 02/02/2014 06:12, Mike Christie wrote:
On 2/1/14 2:42 PM, Or Gerlitz wrote:
At this time (e.g after bind and before sending login) I need only the
session discovery yes/no set param, this goes down to different buffer
management strategy for discovery
On 02/02/2014 06:12, Mike Christie wrote:
On 2/1/14 2:42 PM, Or Gerlitz wrote:
At this time (e.g after bind and before sending login) I need only the
session discovery yes/no set param, this goes down to different buffer
management strategy for discovery vs. normal sessions in iser. I
On Sat, Feb 1, 2014 at 7:14 AM, Mike Christie wrote:
>
> On 1/26/14 8:03 AM, Or Gerlitz wrote:@@ -1406,6 +1406,17 @@
> redirect_reconnect:
>>
>> if ((session->t->caps & CAP_LOGIN_OFFLOAD))
>> goto start_conn;
>>
&g
is a must to cope with
how the
RX buffers are managed in the kernel iser driver for discovery sessions.
Or.
Or Gerlitz (2):
iscsi tools: Add set param for discovery session
iscsi tools: Enhance the discovery code for iser
usr/discovery.c| 13 -
usr/initiator_common.c
For proper discovery support, the iser transport needs the
ISCSI_PARAM_DISCOVERY_SESS hint before the login PDU is sent.
For that end, issue the call to iscsi_session_set_params before
starting the login code in case the transport is iser.
Signed-off-by: Or Gerlitz
---
usr/discovery.c | 13
Add setting of ISCSI_PARAM_DISCOVERY_SESS such that the the transport
can distinguish between discovery to normal sessions.
Signed-off-by: Or Gerlitz
---
usr/initiator_common.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/usr/initiator_common.c b/usr
On 30/12/2013 18:05, orainxiong wrote:
how to solve problem like this:
<3 > [ 434.554641 ] iser : iser_start_rdma_unaligned_sg : Failed
to allocate mem size 66 266240 for copying SGList
<3 > [ 434.592026 ] iser : iser_prepare_write_cmd : Failed to
register write cmd RDMA mem
<3
On 25/10/2013 18:56, Mike Christie wrote:
On 10/24/2013 08:56 AM, Shlomo Pongratz wrote:
>diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
>index 6ac9e17..783f031 100644
>--- a/include/scsi/libiscsi.h
>+++ b/include/scsi/libiscsi.h
>@@ -326,12 +326,15 @@ struct iscsi_session {
>
On 23/10/2013 19:34, Mike Christie wrote:
I am not sure what you are saying. I think when I wrote code in the
first comment I meant code and comments. I just want you to change the
comments in the above functions so instead of having something like:
/**
* iscsi_free_task - free a task
* @tas
On 23/10/2013 19:29, Shlomo Pongratz wrote:
O.K. I'll rebase to Jame's "misc" branch (used to work on his
"for-next" branch).
Mike, aren't we expected to rebase against for-next re code that goes to
the next kernel? anyway, the be2iscsi patches are on both branches.. so
either would be fin
On 23/10/2013 19:12, Mike Christie wrote:
On 10/23/2013 11:07 AM, Mike Christie wrote:
On 10/23/2013 06:16 AM, Shlomo Pongratz wrote:
-Original Message-
From: Mike Christie [mailto:micha...@cs.wisc.edu]
Sent: Monday, October 21, 2013 7:06 PM
To: Or Gerlitz
Cc: open-iscsi
On 17/10/2013 02:23, Mike Christie wrote:
I know you guys sent a new version of the patch, but I am commenting on
just the specific issue below because we started the discussion here.
This chunk in __iscsi_update_cmdsn:
if (max_cmdsn != session->max_cmdsn &&
!iscsi_sna_lt(
On Tue, Sep 17, 2013 at 1:43 PM, Or Gerlitz wrote:
>
> From: Shlomo Pongratz
>
> Replace the session lock with two locks, a "forward" lock and
> a "backwards" lock named frwd_lock and back_lock respectively.
Hi Mike,
So... any comment, the 3.13 merge window
From: Shlomo Pongratz
Restructure iscsi_tcp_r2t_rsp routine in order to avoid allocating r2t from
r2tpool.queue and returning it back in case the parameters rhdr->data_length
and or rhdr->data_offset prohibit the requing. Since the values of these
parameters
are known prior to the allocation, we
From: Shlomo Pongratz
libiscsi_tcp uses two kernel fifos the r2t pool and the r2t queue.
The insertion and deletion from these queues doesn't corespond to the
new forward/backwards session locking paradigm.
That is, in iscsi_tcp_clenup_task which belongs to the RX (backwards)
path, r2t is taken
From: Shlomo Pongratz
Replace the session lock with two locks, a "forward" lock and
a "backwards" lock named frwd_lock and back_lock respectively.
The forward lock protects resources that change while sending a
request to the target, such as cmdsn, queued_cmdsn, and allocating
task from the co
s patch in an accelerated version of the iser initiator we were
able to gain large improvements in IOPS rate in a situation where the burning
bottle-neck was the session lock.
Signed-off-by: Shlomo Pongratz
Signed-off-by: Or Gerlitz
---
drivers/scsi/be2iscsi/be_main.c | 26 +++---
On 20/08/2013 11:08, Mike Christie wrote:
Thanks for doing this and sorry for the lateness.
On 08/08/2013 08:25 AM, Or Gerlitz wrote:
diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index d24a286..6c6631c 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b
On 24/08/2013 00:04, Eddie Wai wrote:
diff --git a/include/iscsi_if.h b/include/iscsi_if.h
index 20f2bc2..b47dde7 100644
--- a/include/iscsi_if.h
+++ b/include/iscsi_if.h
@@ -495,6 +495,10 @@ enum iscsi_param {
ISCSI_PARAM_TGT_RESET_TMO,
ISCSI_PARAM_TARGET_ALIAS,
+
+ ISCSI_PA
On Tue, Aug 13, 2013 at 1:52 AM, Michael Christie wrote:
>
> Tomorrow. Reviewing the qlogic net ones then have this on my todo.
Hi Mike, well... just a kind reminder
Or.
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this
On 13/08/2013 01:52, Michael Christie wrote:
Tomorrow. Reviewing the qlogic net ones then have this on my todo.
cool
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an emai
On Thu, Aug 8, 2013 at 4:25 PM, Or Gerlitz wrote:
> Replace the session lock with two locks, a "forward" lock and
> a "backwards" lock named frwd_lock and back_lock respectively.
>
> The forward lock protects resources that change while sending a
> r
ons.
Using this patch in an accelerated version of the iser initiator we were
able to gain large improvements in IOPS rate in a situation where the burning
bottle-neck was the session lock.
Signed-off-by: Shlomo Pongratz
Signed-off-by: Or Gerlitz
---
drivers/scsi/be2iscsi/be_main.c | 26 +++---
On 31/07/2013 18:58, Michael Christie wrote:
On Jul 31, 2013, at 5:35 AM, Or Gerlitz wrote:
To run discovery over iSER we need to advertize the CAP_TEXT_NEGO capability
towards user space. Also need to make sure the login RX buffer is posted when
SendTargets TEXT PDUs are sent. For that end
On Sat, Aug 3, 2013 at 10:40 PM, Mike Christie wrote:
> On 08/01/2013 05:58 AM, Or Gerlitz wrote:
>> Could you coach me if/how to use the kernel patch or whatever the
>> fastest way to come up with the user space patch?
> I am not completely sure what info you need so let m
On 31/07/2013 19:54, Mike Christie wrote:
Just send to linux-scsi. When it goes there I will respond to the mail
with a Reviewed-by email.
Thanks, will do that.
So now what about the user space part... as minimum we need to apply the
relevant parts from
patch 1/4 below, that is add new param
On Wed, Jul 31, 2013 at 6:58 PM, Michael Christie wrote:
>
> On Jul 31, 2013, at 5:35 AM, Or Gerlitz wrote:
>
> > To run discovery over iSER we need to advertize the CAP_TEXT_NEGO
> capability
> > towards user space. Also need to make sure the login RX buffer is poste
discovery
session.
Signed-off-by: Or Gerlitz
---
changes from V0:
- applied feedback from Mike
-- moved the iscsi_set_param part to libiscsi.c
-- advertize ISCSI_PARAM_DISCOVERY_SESS too in iser_attr_is_visible
To apply this patch need to pick these two patches
[PATCH V1 1/4
On Tue, Jul 2, 2013 at 6:45 PM, Michael Christie wrote:
>
> On Jun 27, 2013, at 2:57 PM, Or Gerlitz wrote:
>
>> On Thu, Jun 27, 2013 at 7:25 PM, Mike Christie wrote:
>>>
>>> On 06/27/2013 08:46 AM, Or Gerlitz wrote:
>>>> @@ -501,6 +503,18
On Thu, Jun 27, 2013 at 7:25 PM, Mike Christie wrote:
>
> On 06/27/2013 08:46 AM, Or Gerlitz wrote:
> > @@ -501,6 +503,18 @@ iscsi_iser_set_param(struct iscsi_cls_conn
> > *cls_conn,
> > return -EPROTO;
> > }
> >
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/ta
the above
behaviour to take place.
Signed-off-by: Or Gerlitz
---
To apply this patch need to pick these two patches
[PATCH V1 1/4] scsi_transport_iscsi: Exporting new attrs for iscsi session and
connection in sysfs
http://marc.info/?l=linux-scsi&m=137225028829588&w=2
[PATCH V1 2/4]
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 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
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 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_RE
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
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 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: f
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 cle
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_irre
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_spe
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 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 clarifica
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 clarifica
On 12/06/2013 18:40, Or Gerlitz wrote:
On 11/06/2013 15:26, Or Gerlitz wrote:
Hi Nic,
I saw that the TCP code is willing to handle TEXT/sendtargets from
within the kernel, so I went a head and added the patch below,I just
have to rush now to other venues and will be able to test that
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
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
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 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 t
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/clarific
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
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
Mike Christie wrote:
> Yeah, I was just wondering if you knew all the ones you needed.
Again, I surely need / must have the source IP address if its
specified in the iface used
for the login. The other two params which I've mentioned are also
needed in some cases, as for "all the ones you needed
On Wed, Jan 4, 2012 at 10:55 PM, Or Gerlitz wrote:
> [..] If you come up with patch I'd love to test that...
I was referring to the iscsi transport code... I'll do the iser patch
and test it as well
Or.
--
You received this message because you are subscribed to the Google Groups
> For iser we will just have to pass what you need into the kernel. Do you
> know exactly what you need passed down in the kernel driver already by any
> chance?
So I wrote in the original post "quick examples are the source ip
address for multi-pathing (e.g when done on 2 paths who use the same
Eddie Wai wrote:
> Yes, I think it would be beneficial to add the passing of the iface_num
> parameter to the transport's ep_connect call so that it can identify
> which iface profile to use. This should help HW transports that have
> support for more than one iface profile. For bnx2i in particul
Hi Mike,
Resending, could you please look on that? (and happy new year)
Or.
-- Forwarded message --
From: Or Gerlitz
Date: Thu, Oct 27, 2011 at 12:55 PM
Subject: using iface attributes for no HW iscsi transport
To: Mike Christie , open-iscsi@googlegroups.com
Mike, yes, it
On 12/21/2011 10:01 AM, Sebastian Riemer wrote:
could you provide quick pointers / 1-2 examples for such API/ABI changes
which aren't deployed in the upstream iser code?
you wrote long emails, I'm asking for one concrete example for that enum
crunching of adding entries
not at the end, can
On 12/20/2011 10:33 PM, Sebastian Riemer wrote:
Have you ever developed/tested the ib_iser module for/with > 2.6.30
kernels? I've seen that there were lots of changes in the whole
open-iscsi kernel stack between 2.6.30 and 2.6.32. The whole ABI has
changed in libiscsi. They added stuff e.g. at
Mike, yes, it could be RTFM question, if indeed this is the case, just
point me to the-M
portion or to some area of the code.. its been a while since we realized
that iser needs
some attributes from user space to the time ep_connect is called.
Quick examples are the source ip address for multi-
On 10/26/2011 4:16 PM, Sebastian Riemer wrote:
Are you doing something on the target? In older tools if the target
returned a login error indicating it was not coming back iscsid would
logout the session destroying /dev/sdXs. I am not sure what is in debian's code.
Indeed, Mike's points need to
fini.
But currently it seems there's no flow for the iser transport to call
dma_unmap when the session goes down, TBD.
Signed-off-by: Or Gerlitz
---
Mike, any idea? do I miss something and the transport can find a slot in
the session teardown flow to go and issue an operation (e.g dma unma
fini.
But currently it seems there's no flow for the iser transport to call
dma_unmap when the session goes down, TBD.
Signed-off-by: Or Gerlitz
---
Mike, any idea? do I miss something and the transport can find a slot in
the session teardown flow to go and issue an operation (e.g dma unma
Rustad, Mark D wrote:
>
> > Mike, Just to make sure I understand the context, DCB vlan ID + pbits
> > and a like setting is targeted for iscsi HW offloads, correct?
>
> It really isn't targeted for iscsi HW offloads. In fact I don't think there
> is any connection at all. It is about honoring the
One socket to bind them all.
>>
>>
>>> -Original Message-
>>> From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com]
>>> On Behalf Of Or Gerlitz
>>> Sent: Monday, October 10, 2011 7:27 AM
>>> To: open-iscsi@googlegroups
Hi,
I haven't followed so far on the DCB support in open-iscsi and will be
happy for help
to get quick catch up / crash course. I saw patches to user space and
now some patches
to upstream. So what is the status of the kernel patches? also do we
have some documentation
(maybe in the git change log
Mike Christie wrote:
>> Under that constraint what you think could be the less tedious way to
>> provide the kernel transport with the session.cmds_max set by the user?
> Modify the ep_connect event to pass it down.
yep, sounds like we can't avoid that, actually I now realized that we
also went
Or Gerlitz wrote:
Mike Christie wrote:
Hey Or, was the problem that you wanted the session->*cmds*max info at
ep_connect time or create_conn time?
let me look on that, I hope to be able to get away with deferring these
resource allocations to a point where I have the session at hand,
On 3/29/2011 11:42 PM, Mike Christie wrote:
I would like to see if anyone would have objections to moving the
mailing list to http://vger.kernel.org/. It is where the linux-kernel,
netdev, scsi (almost all kernel lists) are handled.
Yes, lets do that please, the sooner, the better. I would r
Степан Фёдоров wrote:
Next, i will try to create as many sessions as possible at this
configuration, and report results.
Again, as this goes linearly, I would expect you to be able to establish
twice the number of sessions you could before, that is 246 (2*123)
And now, after resolving this pr
Mike Christie wrote:
Hey Or, was the problem that you wanted the session->*cmds*max info at
ep_connect time or create_conn time?
let me look on that, I hope to be able to get away with deferring these
resource allocations to a point where I have the session at hand, e.g
post bind. Looking on
On Tue, 29 Mar 2011, Or Gerlitz wrote:
> If this patch doesn't work out of the box and you want something simpler
> just to make sure you can reach 256 iscsi/iser sessions, just change
> "params.pool_size
> = ISCSI_DEF_XMIT_CMDS_MAX * 2;" to "params.pool_s
On Tue, 29 Mar 2011, Or Gerlitz wrote:
> Align the iser code to use the actual maximal number of scsi commands
> set for that session when allocating IB FMR resources instead of the
> default max
If this patch doesn't work out of the box and you want something simpler
just to mak
Stepan Fedorov wrote:
About redundancy: we have distributed filesystem (IBM GPFS), on several nodes.
Each node have it's own disks directly attachet to it - there is no shared
storage. So we use GPFS replication to store two replicas of all data. Disks of
virtual machines is actually a files o
Align the iser code to use the actual maximal number of scsi commands
set for that session when allocating IB FMR resources instead of the
default max
Signed-off-by: Or Gerlitz
---
done against Linus tree of commit 036a98263a30930a329e7bb184d5e77f27358e40
compile tested only, will be able to
1 - 100 of 177 matches
Mail list logo
