On Mon, Apr 28, 2008 at 7:13 PM, Mike Christie [EMAIL PROTECTED] wrote:
For bnx2i I was going to run from a hotplug event. When the bnx2i card
is loaded or a port is setup I was going to have it look for session
that are bound to it and login.
First, as we are talking on iscsi which works
Mike Christie wrote:
Login session [iiser: iser_connect:connecting to: 10.8.0.112, port
0xbc0c
face: default, target: iqn.1986-iser: iser_cma_handler:event 0 conn
81022847ce80 id 81023eb82a00
03.com.sun:02:91iser: iser_cma_handler:event 2 conn 81022847ce80
id
On Thu, Feb 19, 2009 at 9:53 PM, Mark van Walraven ma...@netvalue.net.nz
In my experience, noop works well on the initiator. On the target,
deadline is slightly better than noop on the target for the workloads
I see, on my equipment, YMMV.
Thanks a lot for sharing your experience and
Mike Christie wrote:
Does open-iscsi support I/OAT now? If so, from which version?
No. It uses some network API that is not converted to support I/OAT. The
intel guys have sent patches to add it, but they were a little behind
upstream so their patches would break. I think they are working
Mike Christie wrote:
I am not sure what you are asking. Did you look at the patches?
I gave it quick look before asking, I looked now again and I think
to understand this better - lets see if I'm in the correct direction:
The I/OAT related kernel code serves the TCP stack for coping data
from
Mike Christie wrote:
So it seems like we are going to have lots of patches. I would also like to
start sending my kernel patches out in a way that everyone can see them.
Previously to avoid noise on this list, I have been pinging you guys
privately which just does not work so well now
Mike Christie wrote:
Or, I am ccing you because some time ago Erez was working on support
for older RHEL and SLES kernels for OFED. It looks like the patch
below would not be useful to you because iser is supported in those
kernels, but did you guys all need RHEL 4 and maybe SLES 9 support
Mike Christie wrote:
A signature is not going to help you understand that patch will it? :) I do
not think a changelog will help either since it is the first version of a
RFC patch.
Mike, signature is needed and helpful, I assume you sign all the patches
you send to James, isn't it...
that, make iscsi_queuecommand use the _bh form of spin lock/unlock in
the same manner done by iscsi_xmit_task and iscsi_conn_send_pdu
Signed-off-by: Or Gerlitz ogerl...@voltaire.com
---
Mike, I am debugging some enhancement to iser and came a cross this.
I really don't see why it haven't hit anyone
Mike, I am debugging some enhancement to iser and came a cross this.
I really don't see why it haven't hit anyone in the past, any idea?
One more thing which I'd be happy to understand are what the rational behind
the
spin_unlock(host-host_lock) call in iscsi_queuecommand beginning and
Mike Christie micha...@cs.wisc.edu wrote:
The scsi_host_template-queuecommand function is called by scsi-ml with
irqs disabled spin_lock_irqsave(host-host_lock, flags)
thanks for clarifying that, specifically do you refer to scsi.c ::
scsi_dispatch_cmd()? at some point I was LXR-ing for
-by: Or Gerlitz ogerl...@voltaire.com
-
Mike, I'd like to get feedback on this approach/patch, basically I'd
to avoid taking the session lock on the command response flow:
- the kfifo_put call is safe since there's one consumer (xmit flow under
lock for passthrough, and xmit worker for non passthrough
Or Gerlitz wrote:
I can't go over this max when applying my patch of lockless flow for
queuecommand / passthrough
this is the patch I was using till today when I started to suspect it doesn't
yield any
or very little of IOPS over the rest of the patches.
---
drivers/infiniband/ulp/iser
Mike Christie wrote:
So in the end the only lock we would have in the io path is the per task one
and what you were thinking the patch buy us? less cpu usage? more iops? did you
had some proof-of-concept testbed that yielded this under the patch?
Or.
--
You received this message because you
The following patch set removes some inefficiencies in the iser data path
through simplification and reducing the amount of code, using less atomic
operations, avoiding TX interrupts, moving to iscsi passthrough mode,
etc. I did my best to build it as a sequence of patches and not as one
big
path. Use a pre-allocated ring of recv buffers
instead of allocating from kmem cache. A special treatment is given
to the login response buffer whose size must be 8K unlike the size
of buffers used for any other purpose which is 128 bytes.
Signed-off-by: Or Gerlitz ogerl...@voltaire.com
Use a different CQ for send completions, where send completions are
being polled by the interrupt driven recv completion handler.
As such, interrupts aren't used for the send CQ.
Signed-off-by: Or Gerlitz ogerl...@voltaire.com
---
drivers/infiniband/ulp/iser/iscsi_iser.h |3
drivers
Mike Christie wrote:
2. I wasn't sure if there is and if yes what is the transport role in
detecting session failure.
It varies from transport to transport.
For iscsi_tcp we do not really have a nice way to figure out if the
someone just tripped over a cable so that is where the nop comes
Mike Christie wrote:
basically, since the connection establishment framework is IP based, I would
be happy
to just get some source ip in the kernel when ep_connect is called. I saw the
comment on why bind_src_by_address is problematic, but this doesn't apply to
IB/iser.
Which comment are
Mike Christie wrote:
So is there anything in there that is static and can be used to identify the
port?
With srp you can bind a target to a rnic port, right (from srp_add_port
it looks like the add_target file is on the srp classes rnic port
object)? In userspace for the setup then how do
Mike Christie wrote:
I am fine with either. The netdev name (ethX) also has the same problems
where udev can change it. It is there for aliases or vlans where we
cannot use hwaddress since multiple netdevs have the same MAC.
yes, correct both netdevice name and hwaddress suffer from what you
Mike Christie wrote:
The nop watch dog is more of generic catch all problems. I think I was
saying offlist that iscsi_tcp is not able to detect many transport
problems quickly. For example if you just pulled a cable somewhere in
the network, iscsi_tcp may not get some event telling us this. If
Hi Mike,
I'm just reviewing this for the iser disconnect change we're discussing,
and I noted that stop conn is called after ep_disconnect. I wasn't sure if
this is needed, or maybe bug or just something we can live with...
Here's the sequence of events I have collected with the RHEL 5.4
Mike Christie wrote:
The refcouning method sounds good. If iser has cleaned up what gets set
in iscsi_iser_conn_bind once its ep_disconnect has completed, then you
should be ok. So iser_conn-ib_conn has to be NULLd so later when
iscsi_iser_conn_bind is called for the new conn it can be set.
Or Gerlitz wrote:
Mike Christie wrote:
And we will have to watch out for a rmmod while there are ib_conns left
yes, I never was a big favor of rmmod flows, but, I admit they exist...
I do hit this -EEXIST race from time to time when running things like
stop/start sequence.
Now I get
Mike Christie wrote:
So iser_conn-ib_conn has to be NULLd so later when
iscsi_iser_conn_bind is called for the new conn it can be set.
nullifying iser_conn-ib_conn in iser_conn_terminate is problematic since
i_c_terminate is called in the e_disconnect flow where i_c_stop is call later
and if
Mike Christie micha...@cs.wisc.edu wrote:
If the device name and port do not change normally that seems better to
me since it works like the other drivers
just to be on the same page, when you say the other drivers
(=transports) this doesn't include tcp, correct? for the tcp what's
supported
Mike Christie wrote:
Ok let me clarify one other thing too. With the network layer we get a
ethX, or whatever you set up your udev rules to use, for each port. That
is what I am saying above represents the device name and port. The iscsi
drivers that interact with the linux net layer like
Mike Christie wrote:
Maybe that is where I am missing your point. One of the reasons for this
is to tell the kernel to ignore the routing rules and use the port we
want. So I was saying if there is no a API to do this then just add one
like someone did for tcp and the socket code.
Mike,
I am sure this used to work, and quite sure you made some comments on the
subject
now, this isn't working and I can't find your comments, anyway:
using the suggested/similar setting for nop timesout as in the read me
multi-pathing section,
taking a port down causes the nop watch-dog to
Mike Christie wrote:
I have uploaded a new bug fix release to:
http://kernel.org/pub/linux/kernel/people/mnc/open-iscsi/releases/open-iscsi-2.0-871.3.tar.gz
This fixes two bugs:
2. Instead of failover taking node.session.timeo.replacement_timeout
seconds, it takes scsi_cmd-timeout *
Mike Christie wrote:
I started to do a pseudo patch to see how it would work
With the DHCP thing at hand possibly changing the initiator IP address, I think
what we want to do for iser is use NIC names for ifaces as I do now for
iscsi/tcp with the user taking care of NIC name persistently
Mike Christie wrote:
You are not always going to hit the race. It is difficult to hit for me.
I hit it maybe 1/50 runs.
okay, got it.
Failover just mean switching the IO to the other path. It could be in
failover or multibus mode.
okay, so failover comes to say that the multi-path driver
Hi Mike,
Reading through the readme (...) and older posts, I wasn't sure if the
user space iscsi code would keep trying to re-connect for ever, e.g
when replacament timeout = N 0, I understand that after N seconds
all submitted IO would be bounced back to the upper layer (e.g
dm-multipath,
Mike Christie micha...@cs.wisc.edu wrote:
It should retry the login forever. If that does not work on RHEL 5.4 let me
know.
I'll repeat the experiment on early next week and let you know
That question is better asked to the MD list. I have no idea what tunables it
has.
okay, thanks
Or.
Mike Christie wrote:
It should retry the login forever. If that does not work on RHEL 5.4 let me
know.
Mike,
My mistake, it tries also after the recovery (replacement timeout) passed
and I guess for ever.
Or.
--
You received this message because you are subscribed to the Google Groups
Mike Christie wrote:
Spoke to Lefthand and they said linux would need a driver like the
Microsoft Windows DSM one to make doing failover/multipath across all
paths safe.
Andrea, Mike, could you explain in short (or provide a pointer to a
document explaining the windows/vmware DSM need) what
Andrea Sperelli wrote:
The problem is that with dm-mulltipath driver on Linux, we can login
to eache target but each Linux iscsi session is always connected on
the same SAN network interface. Example: Linux: 2 nic San: 4 nic If I
login to the target T, I have 2 iscsi session, one. for each
add support for reporting the current portal (address/port) used
by a connection, which is needed when doing iscsi redirection.
Signed-off-by: Or Gerlitz ogerl...@voltaire.com
---
I followed the related flow in iscsi tcp, to support these
two params, feedback is wellcome
drivers/infiniband/ulp
On Mon, Nov 8, 2010 at 11:14 PM, Mike Christie micha...@cs.wisc.edu wrote:
For ipv6, you need to do something like
if (ib_conn-cma_id-route.addr.dst_addr.ss_family == AF_INET)
// do ipv4 like you did above
else if (ib_conn-cma_id-route.addr.dst_addr.ss_family == AF_INET6)
// do
Hi Mike,
With kernel 2.6.37-rc5 (the latest upstream release) I see some udev related
issue, when doing login (I'm using iscsi-initiator-utils-6.2.0.871-0.16.el5),
the following appears in the system logs
udevd-event[12383]: wait_for_sysfs: waiting for
Mike Christie wrote:
Could you send me your kernel .config?
Yes I do
The other udev messages could also be caused by a older udev and a sysfs
change
can it explain the delay in exposing the luns to the initiator scsi stack?
Or.
--
You received this message because you are subscribed to
Mike Christie wrote:
[...] I think in general the iscsi tools are using sysfs incorrectly.
I think I need to use the sysfs code udev is using.
Again, I'm more not less (...) worried from the original problem of the
luns appearing with delay on the initiator node, I wonder if anyone else
was
Mike Christie wrote:
Do you mean the /dev/sdX's getting created or the kernel scsi scanning code
detecting luns?
I did not see either.
Mike, from this log you can see that the kernel scsi code detected the new scsi
host (98) / lun
on it and assigned the sdd device for that lun, but I can
[...] you can see that the kernel scsi code detected the new scsi host (98) /
lun
on it and assigned the sdd device for that lun, but I can tell that this all
happens only @
16:07:18 which is seven seconds --after-- the lun was detected @ 16:07:11
If we both use the same .config is there
Mike Christie wrote:
Or Gerlitz wrote:
I think you said at some point this may happen if I use old udev
bits, what version of udev you're using?
147. I do not have any udev wait_for_sysfs: waiting messages in my log
so it looks like a udev issue.
yep, using that udev version eliminated
Mike Christie wrote:
It looks like sg_map cheats and does not look at sysfs for this.
Will do one or the other.
It looks like some sg_map26 commands are broken with your kernel config
too now (sg_map26 uses sysfs where sg_map does not).
yes, sg_map26 is very much broken indeed on my kernel...
Mike Christie wrote:
I do not know. We do not do it in Fedora either.
okay, so I guess we'll leave it for that time being...
Or.
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-is...@googlegroups.com.
To
Mike Christie wrote:
I went a different way. In the attached patch we detect the problem when
binding and will force a disconnect of the old ep before binding a new one.
Try it out and let me know.
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -651,8 +651,7 @@ free_addr:
Mike Christie micha...@cs.wisc.edu wrote:
+ ep-conn = cls_conn;
+ cls_conn-ep = ep;
if not, it doesn't look like ep can be null here...
Will fix. Tested offload and did not test software iscsi.
Mike, are you pushing this to 2.6.38? if yes, could you send it to
review @
Mike Christie wrote:
I was working on this patch. It seems to work for iser and cxgbi in the
normal case. iscsi_tcp is broken with it (there is debugging stuff in
iscsi_tcp.c so do not look at it for review purposes).
Thanks for doing that, I tested it with 2.6.37 -- works just fine, e.g
with
Mike Christie wrote:
Hey, I fixed this in the patches and put them in here:
http://git.kernel.org/?p=linux/kernel/git/mnc/linux-2.6-iscsi.git;a=shortlog;h=refs/heads/iscsi
Do you prefer that I send the entire patchset to the list? If so let me
I cloned the tree, built/booted with the iscsi
Mike Christie wrote:
.39. I am still waiting on test results from others, so I think by the
time they are done it will be late in .38
make sense, if possible, lets just have things sent to James whenever they're
ready and not just before the .39 merge window...
It is ok. It is same approach
torn5 wrote:
The only target would be stgt but it has serious data corruption issues
on parallel reads, which get periodically reported in the stgt mailing
list but have never been fixed...
Over the last couple of months, a new iser implementation for stgt was posted
and has gone through few
Mike Christie micha...@cs.wisc.edu wrote:
For writes I am getting 1000MB/s (netperf reports 1100), but for reads I am
getting only 600 MB/s.
what was the perf before the patches?
Or.
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to
Mike Christie wrote:
ccing the iSER maintianer.
Off the top of my head it looks like we could not allocate something
then when handling the error we might be trying to use the null pointer, tight?
Yep, we made a recent fix around that flow, Stepan, could you please try
with a kernel that has
Степан Фёдоров wrote:
i can login only on 123 targets. Next login have this in dmesg:
[ 6811.893602] fmr_pool: fmr_create failed for FMR 184
[ 6811.893779] iser: iser_create_ib_conn_res:unable to alloc mem or create
resource, err -12
If next i logout one session, then i can login one target
On 3/27/2011 7:46 PM, Stepan Fedorov wrote:
We use SLES. May be we can backport this fix to SLES 2.6.32 kernel?
I can look on that, any idea/pointer for public download of the src rpm
for their kernel? Also, I wasn't sure who's the SLES maintainer for
iscsi nowadays, Hannes, is that still you?
?
On 3/27/2011 10:24 AM, Or Gerlitz wrote:
Mike Christie wrote:
ccing the iSER maintianer.
Off the top of my head it looks like we could not allocate something
then when handling the error we might be trying to use the null
pointer, tight?
Yep, we made a recent fix around that flow, Stepan
Степан Фёдоров wrote:
upfront, there's max_fmrs but its zero...). Is that 123 targets for
specific initiator a realistic requirement for your environment?
No. Realistic requirement is at least 256 targets per node.
Each target represents virtual machine in VDS hosting environment, so
we need
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
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 ogerl...@mellanox.com
---
done against Linus tree of commit 036a98263a30930a329e7bb184d5e77f27358e40
compile tested
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 make sure you can
Степан Фёдоров 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
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
Mike Christie micha...@cs.wisc.edu 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
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
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.com
Cc: Mike Christie
Subject: question on the DCB support
Hi,
I haven't followed so far on the DCB support in open
Rustad, Mark D mark.d.rus...@intel.com 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
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 ogerl...@mellanox.com
---
Mike, any idea? do I miss something and the transport can find a slot in
the session teardown flow to go and issue
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 ogerl...@mellanox.com
---
Mike, any idea? do I miss something and the transport can find a slot in
the session teardown flow to go and issue
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
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
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,
Hi Mike,
Resending, could you please look on that? (and happy new year)
Or.
-- Forwarded message --
From: Or Gerlitz ogerl...@mellanox.com
Date: Thu, Oct 27, 2011 at 12:55 PM
Subject: using iface attributes for no HW iscsi transport
To: Mike Christie micha...@cs.wisc.edu, open
Eddie Wai eddie@broadcom.com 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 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
IP
Mike Christie micha...@cs.wisc.edu 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
On Thu, Jun 6, 2013 at 2:16 AM, Mike Christie micha...@cs.wisc.edu wrote:
On 06/05/2013 03:36 PM, Or Gerlitz wrote:
Mike Christie micha...@cs.wisc.edu wrote:
Mike,
Thanks for clarifying things out here,
calls the transport template ep_connect/poll/disconnect and send_pdu calls
likes
On Thu, Jun 6, 2013 at 2:22 AM, Mike Christie micha...@cs.wisc.edu 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
On Thu, Jun 6, 2013 at 6:01 PM, Mike Christie micha...@cs.wisc.edu 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
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.
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
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 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
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
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
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 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 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
On Thu, Jun 20, 2013 at 11:31 PM, Nicholas A. Bellinger n...@linux-iscsi.org
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
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
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 responder_resources
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 from
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
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:
Entering
On Wed, Jun 26, 2013 at 7:29 PM, Mike Christie micha...@cs.wisc.edu 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
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 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:
for the above
behaviour to take place.
Signed-off-by: Or Gerlitz ogerl...@mellanox.com
---
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-scsim=137225028829588w=2
[PATCH V1
1 - 100 of 139 matches
Mail list logo
