Antw: Re: Best way to create multiple TCP flows on 10 Gbps link
Learner Study learner.st...@gmail.com schrieb am 27.08.2014 um 02:13 in
Nachricht
CAP8+hKW=HApS+=vxeaaibtbbd7yzndu4squt+84se99aglc...@mail.gmail.com:
Hi Mike,
Thanks for suggestions
I think you meant,
echo 1 /sys/block/sdX/device/delete
I don't see /sys/block/sdX/device/remove in my setup.
I'm not sure: Is it echo offline /sys/block/sdX/device/state, echo scsi
remove-single-device ${host} ${channel} ${id} ${lun} /proc/scsi/scsi, or
echo 1 /sys/class/scsi_device/${host}:${channel}:${id}:${lun}/device/delete?
How do following FIO options look?
[default]
rw=read
size=4g
bs=1m
ioengine=libaio
direct=1
numjobs=1
filename=/dev/sda
runtime=360
iodepth=256
Thanks for your time!
On Tue, Aug 26, 2014 at 4:49 PM, Michael Christie micha...@cs.wisc.edu
wrote:
On Aug 26, 2014, at 3:11 PM, Learner learner.st...@gmail.com wrote:
Another related observation and some questions;
I am using open iscsi on init with IET on trgt over a single 10gbps link
There are three ip aliases on each side
I have 3 ramdisks exported by IET to init
I do iscsi login 3 times, once using each underlying ip address and notice
that each iscsi session sees all 3 disks.
Is it possible to restrict such that each init only sees one separate disk?
There is no iscsi initiator or target setting for this. The default is to
show all paths (each /dev/sdx is a path to the same device)..
You would have to manually delete some paths by doing
echo 1 /sys/block/sdX/device/remove
When I run fio on each mounted disk, I see that only two underlying tcp
sessions are being used - that limits the perf.
Any ideas on how to overcome this?
How are you matching sessions with devices? It should just be a matter of
running fio on the right devices. If you run:
iscsiadm -m session -P 3
you can see how the sdXs match up with sessions/connections. If you run fio
to a /dev/sdX from each session, you should be seeing IO to all 3 sessions.
Thanks!
Sent from my iPhone
On Aug 26, 2014, at 12:53 PM, Mark Lehrer m...@knm.org wrote:
On Tue, 26 Aug 2014 08:58:46 -0400 Alvin Starr al...@iplink.net wrote:
I am trying to achieve10Gbps in my single initiator/single target
env. (open-iscsi and IET)
On a semi-related note, are there any good guides out there to
tuning Linux for maximum single-socket performance? On my 40 gigabit
You are likely getting hit by the bandwidth-delay product.
Take a look at http://en.wikipedia.org/wiki/Bandwidth-delay_product
and http://www.kehlet.cx/articles/99.html
Thanks that helped get my netcat transfer up over 500MB/sec using IPoIB.
Unfortunately that is still only about 10% of the available bandwidth.
I'll keep on tweaking and see how far I can take it.
Thanks,
Mark
--
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
email to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
--
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
email to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
--
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
email to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
--
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
email to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
--
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 email
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Re: Best way to create multiple TCP flows on 10 Gbps link
On Tue, 26 Aug 2014 13:05:11 -0700 Learner learner.st...@gmail.com wrote: How many iscsi and underlying top sessions are u using? If multiple, pls check if all to sessions are being used. Btw, what tuning did u perform to fix Tcp BDP issue? I'm just doing netcat tests to/from /dev/shm at the moment. I wouldn't consider it fixed necessarily, but the info from this link was useful: http://www.kehlet.cx/articles/99.html Thanks, Mark -- 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 email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Best way to create multiple TCP flows on 10 Gbps link
I had applied the tuning for my 10g link but didn't see much impact. Actually for me tcp is already line rate with 2/3 threads but iscsi/fio read is around 5.5gbps only - with 3/4 fio threads. Perhaps the bottleneck is somewhere else... Thanks! Sent from my iPhone On Aug 27, 2014, at 8:25 AM, Mark Lehrer m...@knm.org wrote: On Tue, 26 Aug 2014 13:05:11 -0700 Learner learner.st...@gmail.com wrote: How many iscsi and underlying top sessions are u using? If multiple, pls check if all to sessions are being used. Btw, what tuning did u perform to fix Tcp BDP issue? I'm just doing netcat tests to/from /dev/shm at the moment. I wouldn't consider it fixed necessarily, but the info from this link was useful: http://www.kehlet.cx/articles/99.html Thanks, Mark -- 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 email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout. -- 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 email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Antw: Re: Best way to create multiple TCP flows on 10 Gbps link
On 08/27/2014 02:24 AM, Ulrich Windl wrote:
Learner Study learner.st...@gmail.com schrieb am 27.08.2014 um 02:13 in
Nachricht
CAP8+hKW=HApS+=vxeaaibtbbd7yzndu4squt+84se99aglc...@mail.gmail.com:
Hi Mike,
Thanks for suggestions
I think you meant,
echo 1 /sys/block/sdX/device/delete
I don't see /sys/block/sdX/device/remove in my setup.
I'm not sure: Is it echo offline /sys/block/sdX/device/state, echo scsi
remove-single-device ${host} ${channel} ${id} ${lun} /proc/scsi/scsi, or
echo 1
/sys/class/scsi_device/${host}:${channel}:${id}:${lun}/device/delete?
To delete a device just do
echo 1 /sys/block/sdX/device/delete
You can also do it through proc if it is enabled for your kernel.
No need to offline the device before deleting. The scsi layer will
handle the device state transitions.
--
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 email
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Re: [PATCH] fix login_timeout timer handling when retrying connect/login
On 8/1/14, 12:33 PM, Mike Christie wrote: On 08/01/2014 05:59 AM, Vikas Chaudhary wrote: On 31/07/14 11:43 pm, Mike Christie micha...@cs.wisc.edu wrote: Was waiting on response from Qlogic/Broadcom. On 07/31/2014 01:19 AM, Roi Dayan wrote: Hi Mike, Is there a new patch? I'm checking I didn't miss it. We did tests with the current patch for now and it worked ok. Thanks, Roi On Friday, July 25, 2014 5:17:44 PM UTC+3, Mike Christie wrote: On Jul 24, 2014, at 4:46 PM, Eddie Wai eddi...@broadcom.com javascript: wrote: On Thu, 2014-07-24 at 12:50 -0500, Mike Christie wrote: Hey Roi, Vikas and Eddie, The attached patch fixes the issue Roi reported where the login_timer was not deleted and so we end up with a infinite loop. Roi, could you test your failure case? Vikas and Eddie, I ccd you guys because it modifies the bnx2i iscsiuio code. There was a issue where iscsiuio was not ready (or the host was not yet ready) and so iscsid would poll iscsiuio for a second or two and it would use the login_timer as a watchdog. A couple weeks ago we hit a issue with be2iscsi where the host was not ready to go so iscsid got code to poll the iscsi/scsi_host. So this patch removes the iscsiuio login_timer use and then also has it use this new common setup polling. For the iscsiuio related changes, it looks like it will actually change the iscsid to iscsiuio re-engagement behavior after the initial 3 failed communication attempts. The old code would delay and re-schedule the login timer actor to retry the iscsiuio communication while the new code would simply failed the entire login attempt. Ah ok, I misread the intention of the code. Let me rework my patch. Should there be a retry limit or timeout to control how long we retry? I was thinking that there could be cases where iscsiuio could not respond and we would want to give up eventually, We have tested this patch for bnx2i and it is working fine. I agree with your assessment above, but will wait for Eddie零 comment on it. Eddie, let me know how long we should wait for before giving up and I will adjust the patch accordingly. Hey, I am just going to make this timeout for this operation 30 seconds. Looking back at some of the threads from when we implemented the original code for bnx2i it seemed like it was only meant to handle a short window where bnx2i/iscsiuio was initializing. Let me know if that is not the case. -- 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 email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
