On Mon, Nov 24, 2014 at 03:02:05PM -0800, Andy Grover wrote:
iBFT-fu = you. Or I can take a stab.. -A
Hi, jumping in here without full context but ...
You can check the iSCSI node records node.discovery_type value for "fw" (iBFT being the most common type of firmware discovery). Non-firmware records will be set to something else like send_targets, static, isns.
- Chris
-------- Forwarded Message -------- Subject: Re: [PATCH 2/3] module-setup: add two functions to determine iBFT Date: Mon, 24 Nov 2014 17:35:13 -0500 From: Vivek Goyal vgoyal@redhat.com To: WANG Chao chaowang@redhat.com CC: kexec@lists.fedoraproject.org, emilne@redhat.com, agrover@redhat.com
On Thu, Nov 13, 2014 at 03:58:42PM +0800, WANG Chao wrote:
If iBFT (iscsi Boot Firmware Table) is configured, we don't have to pass the setup information to 2nd kernel. Because with cmdline argument "rd.iscsi.ibft", dracut will automatically retrieve the setup information from BIOS's ROM or network device's optional-ROM (not from HBA's firmware)
Add two functions to do the check. One is checking if we have "rd.iscsi.ibft" or its equivalents specified in kernel cmdline. The other is to check if the current iscsi session is iBFT.
Because I don't find a reliable way to tell if an iscsi session is using the configurations from iBFT, I marked the second functions as "FIXME" and it always returns false. That means we don't handle iBFT yet. In the future, if someone is asking iBFT support, we can gather some data and finish the work.
If we can't figure out if a connection is using iBFT or not, then we should not have this patch.
I am Ccing Ewan and Andy Grover. May be they have an idea how to figure out if a particular session/connection is using iBFT or not.
Thanks Vivek
Signed-off-by: WANG Chao chaowang@redhat.com
dracut-module-setup.sh | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index bca21ea..780601a 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -422,6 +422,11 @@ kdump_is_iscsi_hw_session() { return 0 }
+# FIXME: determine iBFT +kdump_is_iscsi_ibft_session() {
- return 1
+}
# kernel cmdline must contain these either of the following arguments # for booting off hardware iSCSI: # rd.iscsi.firmware[=1], iscsi_firmware @@ -443,6 +448,27 @@ kdump_is_iscsi_hw_cmdline() { return 1 }
+# kernel cmdline must contain these either of the following arguments +# for booting off iBFT: +# rd.iscsi.ibft[=1], ip=ibft +kdump_is_iscsi_ibft_cmdline() {
- local cmdline
- cmdline="$(cat /proc/cmdline)"
- for arg in $cmdline; do
case "$arg" in"rd.iscsi.ibft" |\"rd.iscsi.ibft=1" |\"ip=ibft")return 0;;esac- done
- return 1
+}
# No ibft handling yet. kdump_setup_iscsi_device() { local path=$1 -- 1.9.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 11/24/14 at 04:54pm, Chris Leech wrote:
On Mon, Nov 24, 2014 at 03:02:05PM -0800, Andy Grover wrote:
iBFT-fu = you. Or I can take a stab.. -A
Hi, jumping in here without full context but ...
You can check the iSCSI node records node.discovery_type value for "fw" (iBFT being the most common type of firmware discovery). Non-firmware records will be set to something else like send_targets, static, isns.
Thanks Chris.
What about hardware iscsi connection, is it right to determine this by its transport class? Is it possible (or common) to manually start a connection using a specific offload driver w/o configurations in HBA's firmware?
Thanks WANG Chao
- Chris
-------- Forwarded Message -------- Subject: Re: [PATCH 2/3] module-setup: add two functions to determine iBFT Date: Mon, 24 Nov 2014 17:35:13 -0500 From: Vivek Goyal vgoyal@redhat.com To: WANG Chao chaowang@redhat.com CC: kexec@lists.fedoraproject.org, emilne@redhat.com, agrover@redhat.com
On Thu, Nov 13, 2014 at 03:58:42PM +0800, WANG Chao wrote:
If iBFT (iscsi Boot Firmware Table) is configured, we don't have to pass the setup information to 2nd kernel. Because with cmdline argument "rd.iscsi.ibft", dracut will automatically retrieve the setup information from BIOS's ROM or network device's optional-ROM (not from HBA's firmware)
Add two functions to do the check. One is checking if we have "rd.iscsi.ibft" or its equivalents specified in kernel cmdline. The other is to check if the current iscsi session is iBFT.
Because I don't find a reliable way to tell if an iscsi session is using the configurations from iBFT, I marked the second functions as "FIXME" and it always returns false. That means we don't handle iBFT yet. In the future, if someone is asking iBFT support, we can gather some data and finish the work.
If we can't figure out if a connection is using iBFT or not, then we should not have this patch.
I am Ccing Ewan and Andy Grover. May be they have an idea how to figure out if a particular session/connection is using iBFT or not.
Thanks Vivek
Signed-off-by: WANG Chao chaowang@redhat.com
dracut-module-setup.sh | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index bca21ea..780601a 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -422,6 +422,11 @@ kdump_is_iscsi_hw_session() { return 0 }
+# FIXME: determine iBFT +kdump_is_iscsi_ibft_session() {
- return 1
+}
# kernel cmdline must contain these either of the following arguments # for booting off hardware iSCSI: # rd.iscsi.firmware[=1], iscsi_firmware @@ -443,6 +448,27 @@ kdump_is_iscsi_hw_cmdline() { return 1 }
+# kernel cmdline must contain these either of the following arguments +# for booting off iBFT: +# rd.iscsi.ibft[=1], ip=ibft +kdump_is_iscsi_ibft_cmdline() {
- local cmdline
- cmdline="$(cat /proc/cmdline)"
- for arg in $cmdline; do
case "$arg" in"rd.iscsi.ibft" |\"rd.iscsi.ibft=1" |\"ip=ibft")return 0;;esac- done
- return 1
+}
# No ibft handling yet. kdump_setup_iscsi_device() { local path=$1 -- 1.9.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On Tue, Nov 25, 2014 at 03:06:43PM +0800, WANG Chao wrote:
On 11/24/14 at 04:54pm, Chris Leech wrote:
On Mon, Nov 24, 2014 at 03:02:05PM -0800, Andy Grover wrote:
iBFT-fu = you. Or I can take a stab.. -A
Hi, jumping in here without full context but ...
You can check the iSCSI node records node.discovery_type value for "fw" (iBFT being the most common type of firmware discovery). Non-firmware records will be set to something else like send_targets, static, isns.
Thanks Chris.
What about hardware iscsi connection, is it right to determine this by its transport class?
In open-iscsi terms a session is an activated node record, and a node record is tied to an iface record. The transport in use is found in the node record as iface.transport_name and can be tcp, iser (for iSCSI over RDMA) or a vendor specific hardware driver.
Is it possible (or common) to manually start a connection using a specific offload driver w/o configurations in HBA's firmware?
Yes, firmware records are generally only used if booting off of iSCSI. Offloaded sessions are created by specifying an offload iface during the discovery command (which is also used to create static entries). And firmware discovery does not always imply offload, as network cards that only have boot ROM support expose iBFT information and use the tcp transport once the OS is up.
- Chris
On 11/25/14 at 02:59pm, Chris Leech wrote:
On Tue, Nov 25, 2014 at 03:06:43PM +0800, WANG Chao wrote:
On 11/24/14 at 04:54pm, Chris Leech wrote:
On Mon, Nov 24, 2014 at 03:02:05PM -0800, Andy Grover wrote:
iBFT-fu = you. Or I can take a stab.. -A
Hi, jumping in here without full context but ...
You can check the iSCSI node records node.discovery_type value for "fw" (iBFT being the most common type of firmware discovery). Non-firmware records will be set to something else like send_targets, static, isns.
Thanks Chris.
What about hardware iscsi connection, is it right to determine this by its transport class?
In open-iscsi terms a session is an activated node record, and a node record is tied to an iface record. The transport in use is found in the node record as iface.transport_name and can be tcp, iser (for iSCSI over RDMA) or a vendor specific hardware driver.
Is it possible (or common) to manually start a connection using a specific offload driver w/o configurations in HBA's firmware?
Yes, firmware records are generally only used if booting off of iSCSI. Offloaded sessions are created by specifying an offload iface during the discovery command (which is also used to create static entries). And firmware discovery does not always imply offload, as network cards that only have boot ROM support expose iBFT information and use the tcp transport once the OS is up.
Thanks! These are very useful.
I have a couple of followup questions:
Will offload iface be created automatically? I mean if firmware has configurations, I don't have to create offload iface by hand and iscsiadm (or something else) will automatically create for me?
I know that /sys/firmware/ibft/ is provided by iBFT and /sys/firmware/iscsi_bootX is provided by vender specific driver.
If there's an iscsi session using the configuration in /sys/firmware/iscsi_bootX, is it hardware iscsi?
What's the different of terms "iBFT" and "hardware iscsi"? Are these two orthogonal terms? Is iBFT software iscsi?
Thanks WANG Chao
On Wed, Nov 26, 2014 at 02:49:12PM +0800, WANG Chao wrote:
On 11/25/14 at 02:59pm, Chris Leech wrote:
On Tue, Nov 25, 2014 at 03:06:43PM +0800, WANG Chao wrote:
On 11/24/14 at 04:54pm, Chris Leech wrote:
On Mon, Nov 24, 2014 at 03:02:05PM -0800, Andy Grover wrote:
iBFT-fu = you. Or I can take a stab.. -A
Hi, jumping in here without full context but ...
You can check the iSCSI node records node.discovery_type value for "fw" (iBFT being the most common type of firmware discovery). Non-firmware records will be set to something else like send_targets, static, isns.
Thanks Chris.
What about hardware iscsi connection, is it right to determine this by its transport class?
In open-iscsi terms a session is an activated node record, and a node record is tied to an iface record. The transport in use is found in the node record as iface.transport_name and can be tcp, iser (for iSCSI over RDMA) or a vendor specific hardware driver.
Is it possible (or common) to manually start a connection using a specific offload driver w/o configurations in HBA's firmware?
Yes, firmware records are generally only used if booting off of iSCSI. Offloaded sessions are created by specifying an offload iface during the discovery command (which is also used to create static entries). And firmware discovery does not always imply offload, as network cards that only have boot ROM support expose iBFT information and use the tcp transport once the OS is up.
Thanks! These are very useful.
I have a couple of followup questions:
Will offload iface be created automatically? I mean if firmware has configurations, I don't have to create offload iface by hand and iscsiadm (or something else) will automatically create for me?
Yes, when iscsiadm is asked to list ifaces it will check sysfs for any new offload iface exposed by kernel drivers and create the records. "iscsiadm -m iface" should generate and show everything. There are reasons to create iface records manually, but it's mostly to bind software iSCSI to specific network interfaces.
I know that /sys/firmware/ibft/ is provided by iBFT and /sys/firmware/iscsi_bootX is provided by vender specific driver.
If there's an iscsi session using the configuration in /sys/firmware/iscsi_bootX, is it hardware iscsi?
I'd have to double check the details, but I'm pretty sure the following is right.
These use the same underlying sysfs code to expose the same type of information. The ibft version is created by a generic module that looks for the firmware table in memory from any boot firmware that supports iBFT, while the iscsi_bootX ones are generated directly by offload iSCSI drivers from device specific information.
What's the different of terms "iBFT" and "hardware iscsi"? Are these two orthogonal terms? Is iBFT software iscsi?
iBFT is an ACPI table to pass information about iSCSI connections to the OS, it can be used by both software and offloaded iSCSI drivers.
- Chris
On 11/25/14 at 11:01pm, Chris Leech wrote:
On Wed, Nov 26, 2014 at 02:49:12PM +0800, WANG Chao wrote:
On 11/25/14 at 02:59pm, Chris Leech wrote:
On Tue, Nov 25, 2014 at 03:06:43PM +0800, WANG Chao wrote:
On 11/24/14 at 04:54pm, Chris Leech wrote:
On Mon, Nov 24, 2014 at 03:02:05PM -0800, Andy Grover wrote:
iBFT-fu = you. Or I can take a stab.. -A
Hi, jumping in here without full context but ...
You can check the iSCSI node records node.discovery_type value for "fw" (iBFT being the most common type of firmware discovery). Non-firmware records will be set to something else like send_targets, static, isns.
Thanks Chris.
What about hardware iscsi connection, is it right to determine this by its transport class?
In open-iscsi terms a session is an activated node record, and a node record is tied to an iface record. The transport in use is found in the node record as iface.transport_name and can be tcp, iser (for iSCSI over RDMA) or a vendor specific hardware driver.
Is it possible (or common) to manually start a connection using a specific offload driver w/o configurations in HBA's firmware?
Yes, firmware records are generally only used if booting off of iSCSI. Offloaded sessions are created by specifying an offload iface during the discovery command (which is also used to create static entries). And firmware discovery does not always imply offload, as network cards that only have boot ROM support expose iBFT information and use the tcp transport once the OS is up.
Thanks! These are very useful.
I have a couple of followup questions:
Will offload iface be created automatically? I mean if firmware has configurations, I don't have to create offload iface by hand and iscsiadm (or something else) will automatically create for me?
Yes, when iscsiadm is asked to list ifaces it will check sysfs for any new offload iface exposed by kernel drivers and create the records. "iscsiadm -m iface" should generate and show everything. There are reasons to create iface records manually, but it's mostly to bind software iSCSI to specific network interfaces.
I know that /sys/firmware/ibft/ is provided by iBFT and /sys/firmware/iscsi_bootX is provided by vender specific driver.
If there's an iscsi session using the configuration in /sys/firmware/iscsi_bootX, is it hardware iscsi?
I'd have to double check the details, but I'm pretty sure the following is right.
These use the same underlying sysfs code to expose the same type of information. The ibft version is created by a generic module that looks for the firmware table in memory from any boot firmware that supports iBFT, while the iscsi_bootX ones are generated directly by offload iSCSI drivers from device specific information.
What's the different of terms "iBFT" and "hardware iscsi"? Are these two orthogonal terms? Is iBFT software iscsi?
iBFT is an ACPI table to pass information about iSCSI connections to the OS, it can be used by both software and offloaded iSCSI drivers.
Thanks again Chris! That should be enough for me.
-
Chris Leech -
WANG Chao