RE: [PATCH 2/3] cxgb4i: main driver files
Hi, Mike,
Yes, will do that for the next submission.
Thanks,
Karen
-Original Message-
From: Mike Christie [mailto:micha...@cs.wisc.edu]
Sent: Tuesday, April 13, 2010 1:42 PM
To: open-iscsi@googlegroups.com
Cc: Rakesh Ranjan; net...@vger.kernel.org; linux-s...@vger.kernel.org;
linux-ker...@vger.kernel.org; Karen Xie; da...@davemloft.net;
james.bottom...@hansenpartnership.com
Subject: Re: [PATCH 2/3] cxgb4i: main driver files
On 04/08/2010 07:14 AM, Rakesh Ranjan wrote:
> +static inline int cxgb4i_ddp_gl_map(struct pci_dev *pdev,
> + struct cxgb4i_gather_list *gl)
> +{
> + int i;
> +
> + for (i = 0; i< gl->nelem; i++) {
> + gl->phys_addr[i] = pci_map_page(pdev, gl->pages[i], 0,
> + PAGE_SIZE,
Hey Rakesh,
I guess we are trying to move away from the pci mapping functions move
to the dma ones. On your next submission, could you fix those up too?
--
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 unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 2/3] cxgb4i: main driver files
On 04/08/2010 07:14 AM, Rakesh Ranjan wrote:
+static inline int cxgb4i_ddp_gl_map(struct pci_dev *pdev,
+ struct cxgb4i_gather_list *gl)
+{
+ int i;
+
+ for (i = 0; i< gl->nelem; i++) {
+ gl->phys_addr[i] = pci_map_page(pdev, gl->pages[i], 0,
+ PAGE_SIZE,
Hey Rakesh,
I guess we are trying to move away from the pci mapping functions move
to the dma ones. On your next submission, could you fix those up too?
--
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 unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: Timeout values for iSCSI
On 04/13/2010 03:23 AM, Christian Iversen wrote: Hi iSCSI guys I've set up iSCSI storage on our servers, using IETD and OpenISCSI. It works and performs great, but I am a little unsure of how to adjust the timeout values properly. On our storage servers, we use heartbeat to achieve HA failover, which works nicely. However, the client machines only try for a fixed amount of time before giving up, so if the failover for some reason does not happen relatively quickly, everything grinds to a halt in a really bad way. I would like to set up open-iscsi to keep trying, preferably at low intervals, and not give up contacting the server. There are quite a few different timeouts, and I have been unable to find any sort of reference documentation for this. Maybe someone here can help? Did you read the README? I tried to document the timeouts that are asked about most frequently on the list. What I'd like is the following: - Never give up trying (or at least try for a month :) The iscsi initiator almost always tries to reconnect to the target. If it gets a successful login then that fails it will try to relogin until the the user runs some iscsiadm command to logout. If you mean you want it to hold onto IO and not fail it, then you want the replacement_timeout/recovery_timeout. There should be info in the README and iscsid.conf about this. If it is not clear let me know. If in the iscsid.conf you see this for node.session.timeo.replacement_timeout then this is what I think you are asking for (that is if you are saying you do not want IO failed) and you want to set the value to 0. # - If the value is 0, IO will be failed immediately. # - If the value is less than 0, IO will remain queued until the session # is logged back in, or until the user runs the logout command. - Try every 1 second - Timeout should work for all stages of the session, be it logged in or not. Can anybody help? Please CC me as I'm not on the list. -- 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 unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 1/2] RFC: iscsi ibft: separate ibft parsing from sysfs interface
On 04/12/2010 01:38 PM, Christopher Barry wrote:
On Mon, 2010-04-12 at 13:06 -0500, micha...@cs.wisc.edu wrote:
From: Mike Christie
Not all iscsi drivers support ibft. For drivers like be2iscsi
that do not but are bootable through a vendor firmware specific
format/process this patch moves the sysfs interface from the ibft code
to a lib module. This then allows userspace tools to search for iscsi boot
info in a common place and in a common format.
ibft iscsi boot info is exported in the same place as it was
before: /sys/firmware/ibft.
vendor/fw boot info gets export in /sys/firmware/iscsi_bootX, where X is the
scsi host number of the HBA. Underneath these parent dirs, the
target, ethernet, and initiator dirs are the same as they were before.
...
===8< snip
+#endif
--
1.6.6.1
Mike,
To be clear, this patch will put ibft data into /var/firmware/ibft only
Not, /var. You meant /sys right (I am not moving it to var. It is
staying in sys).
for those devices that actually have it, but not create a tree for say
NICs that do not currently support it? Wondering if this is a universal
It does not change ibft behavior in any way. If a device supports ibft
and it is setup correctly when you load iscsi_ibft it gets exported in
the exact same place, with the exact files and the files have the same
format.
The patches:
1. separate the interface from the ibft parsing, so we could add a
different interface on like bsg if you wanted.
2. allow drivers that do not support ibft, but support iscsi boot using
some vendor specific process, to be able to export their iscsi boot info
in the same format. These drivers just use a different root dir. Instead
of /sys/firmware/ibft, they use /sys/firmware/iscsi_bootX where X is the
host number of the iscsi HBA that was booted from.
gizmo that will always populate the tree that I can rely on from
userspace during boot.
With these patches, and patches that are being worked on by vendors like
ServerEngines that do not support ibft and use some vendor specific
process, if you just load the iscsi driver, like be2iscsi or qla4xxx,
then they will load the iscsi_boot_sysfs module in the other patch sent
in this patchset, and /sys/firmware/iscsi_bootX will all get populated
with the boot info automagically for you.
The iscsi tools (iscsistart and iscsiadm) will then parse and use this
data like it was ibft data and boot from disks or create records or
whatever. I am attaching the iscsi tools patches here. I am still
working with the be2iscsi guys to test it out.
So with the patches
iscsistart -b
will look for ibft data. If not found then it would look for vendor
specific boot info. If found it would create a session using that
drivers's offload engine.
Thanks,
-C
--
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 unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
diff --git a/include/fw_context.h b/include/fw_context.h
index abdff42..770b41a 100644
--- a/include/fw_context.h
+++ b/include/fw_context.h
@@ -54,6 +54,8 @@ struct boot_context {
char mask[18];
char lun[17];
char vlan[15];
+
+ char scsi_host_name[64];
};
extern int fw_get_entry(struct boot_context *context);
diff --git a/usr/iface.c b/usr/iface.c
index 27b59d0..9c74117 100644
--- a/usr/iface.c
+++ b/usr/iface.c
@@ -778,31 +778,62 @@ void iface_link_ifaces(struct list_head *ifaces)
iface_for_each_iface(ifaces, 1, &nr_found, iface_link);
}
-void iface_setup_from_boot_context(struct iface_rec *iface,
+/**
+ * iface_setup_from_boot_context - setup iface from boot context info
+ * @iface: iface t setup
+ * @context: boot context info
+ *
+ * Returns 1 if setup for offload.
+ */
+int iface_setup_from_boot_context(struct iface_rec *iface,
struct boot_context *context)
{
if (strlen(context->initiatorname))
strlcpy(iface->iname, context->initiatorname,
sizeof(iface->iname));
- if (strlen(context->iface)) {
- if (!net_get_transport_name_from_netdev(context->iface,
- iface->transport_name)) {
- /* set up for access through offload card */
- memset(iface->name, 0, sizeof(iface->name));
- snprintf(iface->name, sizeof(iface->name),
-"%s.%s", iface->transport_name,
-context->mac);
-
- strlcpy(iface->netdev, context->iface,
- sizeof(iface->netdev));
- strlcpy(iface->hwaddress, context->mac,
- sizeof(iface->hwaddress));
-
Timeout values for iSCSI
Hi iSCSI guys I've set up iSCSI storage on our servers, using IETD and OpenISCSI. It works and performs great, but I am a little unsure of how to adjust the timeout values properly. On our storage servers, we use heartbeat to achieve HA failover, which works nicely. However, the client machines only try for a fixed amount of time before giving up, so if the failover for some reason does not happen relatively quickly, everything grinds to a halt in a really bad way. I would like to set up open-iscsi to keep trying, preferably at low intervals, and not give up contacting the server. There are quite a few different timeouts, and I have been unable to find any sort of reference documentation for this. Maybe someone here can help? What I'd like is the following: - Never give up trying (or at least try for a month :) - Try every 1 second - Timeout should work for all stages of the session, be it logged in or not. Can anybody help? Please CC me as I'm not on the list. -- Med venlig hilsen / Best regards Christian Iversen Sikkerhed.org ApS Fuglebakkevej 88 E-mail: supp...@sikkerhed.org 1. sal Web: www.sikkerhed.org DK-2000 Frederiksberg Direkte: c...@sikkerhed.org -- 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 unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 2/2] RFC: iscsi ibft: convert iscsi_ibft module to iscsi boot lib
On 04/12/2010 10:36 PM, Konrad Rzeszutek Wilk wrote:
> On Monday 12 April 2010 22:32:33 Mike Christie wrote:
>> On 04/12/2010 09:21 PM, Konrad Rzeszutek Wilk wrote:
+ * Helper routiners to check to determine if the entry is valid
+ * in the proper iBFT structure.
+ */
+static mode_t ibft_check_nic_for(void *data, int type)
+{
+ struct ibft_kobject *entry = data;
+ struct ibft_nic *nic = entry->nic;
+ mode_t rc = 0;
+
+ switch (type) {
+ case ISCSI_BOOT_ETH_INDEX:
+ case ISCSI_BOOT_ETH_FLAGS:
+ rc = 1;
>>>
>>> Did you mean for that value?
>>>
+ break;
+ case ISCSI_BOOT_ETH_IP_ADDR:
+ if (memcmp(nic->ip_addr, nulls, sizeof(nic->ip_addr)))
+ rc = S_IRUGO;
+ break;
+ case ISCSI_BOOT_ETH_SUBNET_MASK:
+ if (nic->subnet_mask_prefix)
+ rc = S_IRUGO;
+ break;
+ case ISCSI_BOOT_ETH_ORIGIN:
+ rc = 1;
>>>
>>> and this one as well?
>>
>> I did not. They should be S_IRUGO. Do you want me to resubmit the
>> patches or are you just going to edit those two lines if you merge them?
>
> No need to resend them (unless Peter eyes found something I missed).
Nope, that's all I see.
--
Peter
Sanity's just a one trick pony anyway. You only get one trick -- rational
thinking -- but when you're good and crazy, the sky's the limit!
-- The Tick
--
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 unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
RE: [Iscsitarget-devel] Fwd: target creation and isns scn notification
Gopu Krishnan [mailto:gopu.0...@gmail.com] wrote: > > Hi All, > > In IET code, we create the target before the isns init. I > understand that for per target we do have the isns scn > registration. But we do SCN registration only for the targets > which are created by ietadm. From that point is what the > use_isns got enabled. > > I would like to conclude, that the SCN registration wont > happen for targets which are created via ietd.conf. > SCN registration will happen only for target which are > created by ietadm. > > Moreover the device registration also wont happen for the > targets created by ietd.conf. Only Device Query happens on time-out. > > Please confirm my observations. We'll take a look into SCN registrations in the next release. Thank you for your observations though. -Ross __ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. -- 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 unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 1/2] RFC: iscsi ibft: separate ibft parsing from sysfs interface
On Mon, 2010-04-12 at 13:06 -0500, micha...@cs.wisc.edu wrote: > From: Mike Christie > > Not all iscsi drivers support ibft. For drivers like be2iscsi > that do not but are bootable through a vendor firmware specific > format/process this patch moves the sysfs interface from the ibft code > to a lib module. This then allows userspace tools to search for iscsi boot > info in a common place and in a common format. > > ibft iscsi boot info is exported in the same place as it was > before: /sys/firmware/ibft. > > vendor/fw boot info gets export in /sys/firmware/iscsi_bootX, where X is the > scsi host number of the HBA. Underneath these parent dirs, the > target, ethernet, and initiator dirs are the same as they were before. > ... ===8< snip > +#endif > -- > 1.6.6.1 > Mike, To be clear, this patch will put ibft data into /var/firmware/ibft only for those devices that actually have it, but not create a tree for say NICs that do not currently support it? Wondering if this is a universal gizmo that will always populate the tree that I can rely on from userspace during boot. Thanks, -C -- 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 unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 2/2] RFC: iscsi ibft: convert iscsi_ibft module to iscsi boot lib
On Monday 12 April 2010 22:32:33 Mike Christie wrote:
> On 04/12/2010 09:21 PM, Konrad Rzeszutek Wilk wrote:
> >> + * Helper routiners to check to determine if the entry is valid
> >> + * in the proper iBFT structure.
> >> + */
> >> +static mode_t ibft_check_nic_for(void *data, int type)
> >> +{
> >> + struct ibft_kobject *entry = data;
> >> + struct ibft_nic *nic = entry->nic;
> >> + mode_t rc = 0;
> >> +
> >> + switch (type) {
> >> + case ISCSI_BOOT_ETH_INDEX:
> >> + case ISCSI_BOOT_ETH_FLAGS:
> >> + rc = 1;
> >
> > Did you mean for that value?
> >
> >> + break;
> >> + case ISCSI_BOOT_ETH_IP_ADDR:
> >> + if (memcmp(nic->ip_addr, nulls, sizeof(nic->ip_addr)))
> >> + rc = S_IRUGO;
> >> + break;
> >> + case ISCSI_BOOT_ETH_SUBNET_MASK:
> >> + if (nic->subnet_mask_prefix)
> >> + rc = S_IRUGO;
> >> + break;
> >> + case ISCSI_BOOT_ETH_ORIGIN:
> >> + rc = 1;
> >
> > and this one as well?
>
> I did not. They should be S_IRUGO. Do you want me to resubmit the
> patches or are you just going to edit those two lines if you merge them?
No need to resend them (unless Peter eyes found something I missed).
--
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 unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 1/2] RFC: iscsi ibft: separate ibft parsing from sysfs interface
On Monday 12 April 2010 14:06:17 micha...@cs.wisc.edu wrote: > From: Mike Christie > > Not all iscsi drivers support ibft. For drivers like be2iscsi > that do not but are bootable through a vendor firmware specific > format/process this patch moves the sysfs interface from the ibft code > to a lib module. This then allows userspace tools to search for iscsi boot > info in a common place and in a common format. > > ibft iscsi boot info is exported in the same place as it was > before: /sys/firmware/ibft. > > vendor/fw boot info gets export in /sys/firmware/iscsi_bootX, where X is > the scsi host number of the HBA. Underneath these parent dirs, the > target, ethernet, and initiator dirs are the same as they were before. > > This patch was made over the ibft-2.6 tree's ibft-1.03 branch: > http://git.kernel.org/?p=linux/kernel/git/konrad/ibft-2.6.git;a=shortlog;h= >refs/heads/ibft-1.03 > > > Signed-off-by: Mike Christie > --- Looks good to my eyes. Let me run it tomorrow through my regression bucket before I stick on the git tree. -- 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 unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 2/2] RFC: iscsi ibft: convert iscsi_ibft module to iscsi boot lib
On Monday 12 April 2010 14:06:18 you wrote:
> From: Mike Christie
>
> This patch just converts the iscsi_ibft module to the
> iscsi boot sysfs lib module.
>
> This patch was made over the ibft-2.6 tree's ibft-1.03 branch:
> http://git.kernel.org/?p=linux/kernel/git/konrad/ibft-2.6.git;a=shortlog;h=
>refs/heads/ibft-1.03
>
> Signed-off-by: Mike Christie
>
I've only two comments:
.. snip..
> /*
> + * Helper routiners to check to determine if the entry is valid
> + * in the proper iBFT structure.
> + */
> +static mode_t ibft_check_nic_for(void *data, int type)
> +{
> + struct ibft_kobject *entry = data;
> + struct ibft_nic *nic = entry->nic;
> + mode_t rc = 0;
> +
> + switch (type) {
> + case ISCSI_BOOT_ETH_INDEX:
> + case ISCSI_BOOT_ETH_FLAGS:
> + rc = 1;
Did you mean for that value?
> + break;
> + case ISCSI_BOOT_ETH_IP_ADDR:
> + if (memcmp(nic->ip_addr, nulls, sizeof(nic->ip_addr)))
> + rc = S_IRUGO;
> + break;
> + case ISCSI_BOOT_ETH_SUBNET_MASK:
> + if (nic->subnet_mask_prefix)
> + rc = S_IRUGO;
> + break;
> + case ISCSI_BOOT_ETH_ORIGIN:
> + rc = 1;
and this one as well?
--
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 unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: Over one million IOPS using software iSCSI and 10 Gbit Ethernet
Pasi Kärkkäinen, on 04/12/2010 11:54 PM wrote: On Fri, Feb 05, 2010 at 02:10:32PM +0300, Vladislav Bolkhovitin wrote: For me personally it was funny to see how MS presents in the WinHEC presentation (http://download.microsoft.com/download/5/E/6/5E66B27B-988B-4F50-AF3A-C2FF1E62180F/COR-T586_WH08.pptx) that they have 1.1GB/s from 4 connections. In the beginning of 2008 I saw a *single* dd pushing data on that rate over a *single* connection from Linux initiator to iSCSI-SCST target using regular Myricom hardware without any special acceleration. I didn't know how proud I must have been for Linux :). Btw was this over 10 Gig Ethernet? Did you have to tweak something special to achieve this, either on the initiator, or on the target? Nothing special. It was for plain dd writes. Vlad -- 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 unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
