Re: Fwd: Re: [PATCH 2/3] module-setup: add two functions to determine iBFT

[Chris Leech]

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 
> To: WANG Chao 
> CC: [e-mail], [e-mail], [e-mail]
>
> 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
> >
> > 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
> > [e-mail]
> > https://lists.fedoraproject.org/mailman/listinfo/kexec

Fwd: Re: [PATCH 2/3] module-setup: add two functions to determine iBFT

[WANG Chao]

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 
> > To: WANG Chao 
> > CC: [e-mail], [e-mail], [e-mail]
> >
> > 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
> > >
> > > 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
> > > [e-mail]
> > > https://lists.fedoraproject.org/mailman/listinfo/kexec

Fwd: Re: [PATCH 2/3] module-setup: add two functions to determine iBFT

[Chris Leech]

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

Fwd: Re: [PATCH 2/3] module-setup: add two functions to determine iBFT

[WANG Chao]

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

Fwd: Re: [PATCH 2/3] module-setup: add two functions to determine iBFT

[Chris Leech]

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

Fwd: Re: [PATCH 2/3] module-setup: add two functions to determine iBFT

[WANG Chao]

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.