Re: Mapping Target Name with Device
On 5 Feb 2009 at 16:00, Praveen P wrote: > Hello all, > > Before I had posted one trouble related to open-iscsi which was sorted with > the help of Ross and Lars. > > I could complete my perl project related to ietadm and open-iscsi . > > All the information regarding the targets obtained are displayed in a web > page. > Now my client need to display the size of each targets obtained also. > > Using the command fdisk -l i can see all the devices available and i have > the all the available target names also. > > How can i map the each target name with the corresponding device ? Hi, I just discovered "lsscsi --transport" on my SLES10 SP1 system: The /usr/bin/lsscsi comes from package "scsi". It will display things like this: # lsscsi --transport [0:0:0:0]disksas:0x5000c5920c31 - [0:0:1:0]disksas:0x50e01240f9e2 - _tport: no sas_address, wd=/sys/class/sas_device/host0 [0:1:2:0]disk/dev/sda [1:0:0:0]cd/dvd /dev/sr0 [2:0:0:0]disk/dev/sdb [135:0:0:111]diskiqn.1986- 03.com.hp:fcgw.mpx100:rkdvmis2.0.50001fe1500c1f20.50001fe1500c1f2c,t,0x0 /dev/sdd Reminds me of: When will the system run out of SCSI host adapters? when playing with iSCSI, those numbers increase quickly, and I'm afraid that Linux doesn't recycle them; does it? Regards, Ulrich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@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 -~--~~~~--~~--~--~---
RE: [RFC] : network configuration for iscsi hba
Okay, I think cxgb3i driver can work with the proposed mechanism. Thanks, Karen -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Anil Veerabhadrappa Sent: Thursday, February 05, 2009 6:29 PM To: open-iscsi@googlegroups.com Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin Li Subject: RE: [RFC] : network configuration for iscsi hba On Thu, 2009-02-05 at 17:34 -0800, Karen Xie wrote: > For dhcp, I am just thinking of the cases where one physical NIC have > multiple IP addresses, maybe one is for iscsi only, one for RDMA, or > another for admin/control traffic. They can operate in different subnet RDMA shares ip/mac address with host stack, right? Even in the example provided above the device should support 3 at least separate MAC addresses, so by specifying multiple iface definitions user should be able to get this configuration working. > and managed by different DHCP servers. Maybe this is not typical setup? > > For the set_config, say a NIC does not support IPv6 but received a > request to set it. So how should the driver treat any setting it does > not support? Ignore or return an error? > This should be considered as user error. Users are expected to create iface definitions based on guidelines (supported parameter list) outlined in driver's README file. > -Original Message- > From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] > On Behalf Of Anil Veerabhadrappa > Sent: Thursday, February 05, 2009 5:01 PM > To: open-iscsi@googlegroups.com > Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin Li > Subject: RE: [RFC] : network configuration for iscsi hba > > > On Thu, 2009-02-05 at 16:36 -0800, Karen Xie wrote: > > If it is dhcp, does the dhcp server settings need to be provided? Or > it > > is going to be handled outside of iscsi? > > > dhcp setting should be zero-conf right? It works based on initial > broadcast request, DHCPDISCOVER and subsequent unicast exchange between > dhcp client and the server. Are you referring to choosing the preferred > dhcp server if more than one is present in the network? > > > > Also a question about the set_net_config, suppose a list of parameters > > are send down, if one or more values are not supported, does the > > operation marked as fail and the user has re-do the iface file (to > edit > > out the unsupported values)? > > > > Please provide specific examples for discussion. Any device specific > limitation will be handled by the corresponding driver, our objective > here is to define a generic interface that works for > cxgb3i/qla4xxx/bnx2i/... > > > Thanks, > > Karen > > > > -Original Message- > > From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] > > On Behalf Of Anil Veerabhadrappa > > Sent: Thursday, February 05, 2009 4:21 PM > > To: open-iscsi@googlegroups.com > > Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin > Li > > Subject: RE: [RFC] : network configuration for iscsi hba > > > > > > On Thu, 2009-02-05 at 16:00 -0800, Karen Xie wrote: > > > Thanks, > > > What are the possible values of "ISCSI_NET_CFG_BOOTPROTO"? > > > > > > > static and dhcp > > > > > > > Karen > > > > > > -Original Message- > > > From: open-iscsi@googlegroups.com > [mailto:open-is...@googlegroups.com] > > > On Behalf Of Anil Veerabhadrappa > > > Sent: Thursday, February 05, 2009 3:23 PM > > > To: open-iscsi@googlegroups.com > > > Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; > Benjamin > > Li > > > Subject: RE: [RFC] : network configuration for iscsi hba > > > > > > > > > On Thu, 2009-02-05 at 14:33 -0800, Karen Xie wrote: > > > > -Original Message- > > > > From: open-iscsi@googlegroups.com > > [mailto:open-is...@googlegroups.com] > > > > On Behalf Of Anil Veerabhadrappa > > > > Sent: Thursday, February 05, 2009 11:23 AM > > > > To: open-iscsi@googlegroups.com; micha...@cs.wisc.edu > > > > Cc: mchri...@redhat.com; mc...@broadcom.com; be...@broadcom.com; > > > > ani...@broadcom.com > > > > Subject: [RFC] : network configuration for iscsi hba > > > > > > > > > > > > Hi, > > > > > > > >We'd like to propose a general scheme for configuring network > > > > parameters (IP address/mask/DHCP, etc) for iSCSI NICs that use a > > > private > > > > IP address. The current scheme of using sysfs is not very good > > because > > > > bootproto, IP address, netmask, VLAN ID, etc all need to be set > > > > together. Having separate sysfs entries and updating them > separately > > > and > > > > independently will not work. Putting everything in a netlink > message > > > > seems to be a better solution. After weighing different solutions, > > we > > > > feel expanding existing netlink family, NETLINK_ISCSI between > iscsid > > > and > > > > scsi_transport_iscsi is a flexible solution which allows > information > > > > flow to be initiated from either side. Also this solution is > >
RE: [RFC] : network configuration for iscsi hba
On Thu, 2009-02-05 at 17:34 -0800, Karen Xie wrote: > For dhcp, I am just thinking of the cases where one physical NIC have > multiple IP addresses, maybe one is for iscsi only, one for RDMA, or > another for admin/control traffic. They can operate in different subnet RDMA shares ip/mac address with host stack, right? Even in the example provided above the device should support 3 at least separate MAC addresses, so by specifying multiple iface definitions user should be able to get this configuration working. > and managed by different DHCP servers. Maybe this is not typical setup? > > For the set_config, say a NIC does not support IPv6 but received a > request to set it. So how should the driver treat any setting it does > not support? Ignore or return an error? > This should be considered as user error. Users are expected to create iface definitions based on guidelines (supported parameter list) outlined in driver's README file. > -Original Message- > From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] > On Behalf Of Anil Veerabhadrappa > Sent: Thursday, February 05, 2009 5:01 PM > To: open-iscsi@googlegroups.com > Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin Li > Subject: RE: [RFC] : network configuration for iscsi hba > > > On Thu, 2009-02-05 at 16:36 -0800, Karen Xie wrote: > > If it is dhcp, does the dhcp server settings need to be provided? Or > it > > is going to be handled outside of iscsi? > > > dhcp setting should be zero-conf right? It works based on initial > broadcast request, DHCPDISCOVER and subsequent unicast exchange between > dhcp client and the server. Are you referring to choosing the preferred > dhcp server if more than one is present in the network? > > > > Also a question about the set_net_config, suppose a list of parameters > > are send down, if one or more values are not supported, does the > > operation marked as fail and the user has re-do the iface file (to > edit > > out the unsupported values)? > > > > Please provide specific examples for discussion. Any device specific > limitation will be handled by the corresponding driver, our objective > here is to define a generic interface that works for > cxgb3i/qla4xxx/bnx2i/... > > > Thanks, > > Karen > > > > -Original Message- > > From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] > > On Behalf Of Anil Veerabhadrappa > > Sent: Thursday, February 05, 2009 4:21 PM > > To: open-iscsi@googlegroups.com > > Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin > Li > > Subject: RE: [RFC] : network configuration for iscsi hba > > > > > > On Thu, 2009-02-05 at 16:00 -0800, Karen Xie wrote: > > > Thanks, > > > What are the possible values of "ISCSI_NET_CFG_BOOTPROTO"? > > > > > > > static and dhcp > > > > > > > Karen > > > > > > -Original Message- > > > From: open-iscsi@googlegroups.com > [mailto:open-is...@googlegroups.com] > > > On Behalf Of Anil Veerabhadrappa > > > Sent: Thursday, February 05, 2009 3:23 PM > > > To: open-iscsi@googlegroups.com > > > Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; > Benjamin > > Li > > > Subject: RE: [RFC] : network configuration for iscsi hba > > > > > > > > > On Thu, 2009-02-05 at 14:33 -0800, Karen Xie wrote: > > > > -Original Message- > > > > From: open-iscsi@googlegroups.com > > [mailto:open-is...@googlegroups.com] > > > > On Behalf Of Anil Veerabhadrappa > > > > Sent: Thursday, February 05, 2009 11:23 AM > > > > To: open-iscsi@googlegroups.com; micha...@cs.wisc.edu > > > > Cc: mchri...@redhat.com; mc...@broadcom.com; be...@broadcom.com; > > > > ani...@broadcom.com > > > > Subject: [RFC] : network configuration for iscsi hba > > > > > > > > > > > > Hi, > > > > > > > >We'd like to propose a general scheme for configuring network > > > > parameters (IP address/mask/DHCP, etc) for iSCSI NICs that use a > > > private > > > > IP address. The current scheme of using sysfs is not very good > > because > > > > bootproto, IP address, netmask, VLAN ID, etc all need to be set > > > > together. Having separate sysfs entries and updating them > separately > > > and > > > > independently will not work. Putting everything in a netlink > message > > > > seems to be a better solution. After weighing different solutions, > > we > > > > feel expanding existing netlink family, NETLINK_ISCSI between > iscsid > > > and > > > > scsi_transport_iscsi is a flexible solution which allows > information > > > > flow to be initiated from either side. Also this solution is > > flexible > > > > and elegantly handles network devices with multiple IP addresses. > > > > > > > >The objective of this proposal is to make this interface common > > for > > > > all iscsi offload solutions supported by open-iscsi. We would like > > to > > > > hear comments and suggestions from other iscsi offload vendors in > > > > defining this interface. > > > > > > > > Regards, > > > > Anil Veerabhadrappa >
RE: [RFC] : network configuration for iscsi hba
For dhcp, I am just thinking of the cases where one physical NIC have multiple IP addresses, maybe one is for iscsi only, one for RDMA, or another for admin/control traffic. They can operate in different subnet and managed by different DHCP servers. Maybe this is not typical setup? For the set_config, say a NIC does not support IPv6 but received a request to set it. So how should the driver treat any setting it does not support? Ignore or return an error? -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Anil Veerabhadrappa Sent: Thursday, February 05, 2009 5:01 PM To: open-iscsi@googlegroups.com Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin Li Subject: RE: [RFC] : network configuration for iscsi hba On Thu, 2009-02-05 at 16:36 -0800, Karen Xie wrote: > If it is dhcp, does the dhcp server settings need to be provided? Or it > is going to be handled outside of iscsi? > dhcp setting should be zero-conf right? It works based on initial broadcast request, DHCPDISCOVER and subsequent unicast exchange between dhcp client and the server. Are you referring to choosing the preferred dhcp server if more than one is present in the network? > Also a question about the set_net_config, suppose a list of parameters > are send down, if one or more values are not supported, does the > operation marked as fail and the user has re-do the iface file (to edit > out the unsupported values)? > Please provide specific examples for discussion. Any device specific limitation will be handled by the corresponding driver, our objective here is to define a generic interface that works for cxgb3i/qla4xxx/bnx2i/... > Thanks, > Karen > > -Original Message- > From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] > On Behalf Of Anil Veerabhadrappa > Sent: Thursday, February 05, 2009 4:21 PM > To: open-iscsi@googlegroups.com > Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin Li > Subject: RE: [RFC] : network configuration for iscsi hba > > > On Thu, 2009-02-05 at 16:00 -0800, Karen Xie wrote: > > Thanks, > > What are the possible values of "ISCSI_NET_CFG_BOOTPROTO"? > > > > static and dhcp > > > > Karen > > > > -Original Message- > > From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] > > On Behalf Of Anil Veerabhadrappa > > Sent: Thursday, February 05, 2009 3:23 PM > > To: open-iscsi@googlegroups.com > > Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin > Li > > Subject: RE: [RFC] : network configuration for iscsi hba > > > > > > On Thu, 2009-02-05 at 14:33 -0800, Karen Xie wrote: > > > -Original Message- > > > From: open-iscsi@googlegroups.com > [mailto:open-is...@googlegroups.com] > > > On Behalf Of Anil Veerabhadrappa > > > Sent: Thursday, February 05, 2009 11:23 AM > > > To: open-iscsi@googlegroups.com; micha...@cs.wisc.edu > > > Cc: mchri...@redhat.com; mc...@broadcom.com; be...@broadcom.com; > > > ani...@broadcom.com > > > Subject: [RFC] : network configuration for iscsi hba > > > > > > > > > Hi, > > > > > >We'd like to propose a general scheme for configuring network > > > parameters (IP address/mask/DHCP, etc) for iSCSI NICs that use a > > private > > > IP address. The current scheme of using sysfs is not very good > because > > > bootproto, IP address, netmask, VLAN ID, etc all need to be set > > > together. Having separate sysfs entries and updating them separately > > and > > > independently will not work. Putting everything in a netlink message > > > seems to be a better solution. After weighing different solutions, > we > > > feel expanding existing netlink family, NETLINK_ISCSI between iscsid > > and > > > scsi_transport_iscsi is a flexible solution which allows information > > > flow to be initiated from either side. Also this solution is > flexible > > > and elegantly handles network devices with multiple IP addresses. > > > > > >The objective of this proposal is to make this interface common > for > > > all iscsi offload solutions supported by open-iscsi. We would like > to > > > hear comments and suggestions from other iscsi offload vendors in > > > defining this interface. > > > > > > Regards, > > > Anil Veerabhadrappa > > > > > > > > > Proposal to add netlink message type: > > > - > > > 3 new netlink message types are required to support network > config > > > message exchange between user and kernel components, > > > 1. ISCSI_UEVENT_SET_NET_CONFIG - push iface info to driver to > > > configure > > > an iscsi network interface > > > 2. ISCSI_UEVENT_GET_NET_CONFIG - get MAC address list, etc' > > > 3. ISCSI_KEVENT_NET_CONFIG - propagate attribute changes > > > from > > > adapter to iscsid (e.g. advertise newly obtained dhcp address) > > > > > > iscsid will use this netlink messages to pass network > > configuration > > > between user mode applicat
Where is the open-iscsi wiki site?
To open-iscsi@googlegroups.com, the wiki site http://www.open-iscsi.org/cgi-bin/wiki.pl/Roadmap stated in http://www.open-iscsi.org/docs/README seems not work, it reported an error, Could not create /home/admin/mainwebsite_cgi/open-iscsi: No such file or directory Other wiki pages not work, too, http://www.open-iscsi.org/cgi-bin/wiki.pl/Performance-setup So where is the real open-iscsi wiki site? Thanks, -- Cheng Renquan, Shenzhen, China Johnny Carson - "I was so naive as a kid I used to sneak behind the barn and do nothing." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@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 -~--~~~~--~~--~--~---
RE: [RFC] : network configuration for iscsi hba
On Thu, 2009-02-05 at 16:36 -0800, Karen Xie wrote:
> If it is dhcp, does the dhcp server settings need to be provided? Or it
> is going to be handled outside of iscsi?
>
dhcp setting should be zero-conf right? It works based on initial
broadcast request, DHCPDISCOVER and subsequent unicast exchange between
dhcp client and the server. Are you referring to choosing the preferred
dhcp server if more than one is present in the network?
> Also a question about the set_net_config, suppose a list of parameters
> are send down, if one or more values are not supported, does the
> operation marked as fail and the user has re-do the iface file (to edit
> out the unsupported values)?
>
Please provide specific examples for discussion. Any device specific
limitation will be handled by the corresponding driver, our objective
here is to define a generic interface that works for
cxgb3i/qla4xxx/bnx2i/...
> Thanks,
> Karen
>
> -Original Message-
> From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
> On Behalf Of Anil Veerabhadrappa
> Sent: Thursday, February 05, 2009 4:21 PM
> To: open-iscsi@googlegroups.com
> Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin Li
> Subject: RE: [RFC] : network configuration for iscsi hba
>
>
> On Thu, 2009-02-05 at 16:00 -0800, Karen Xie wrote:
> > Thanks,
> > What are the possible values of "ISCSI_NET_CFG_BOOTPROTO"?
> >
>
> static and dhcp
>
>
> > Karen
> >
> > -Original Message-
> > From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
> > On Behalf Of Anil Veerabhadrappa
> > Sent: Thursday, February 05, 2009 3:23 PM
> > To: open-iscsi@googlegroups.com
> > Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin
> Li
> > Subject: RE: [RFC] : network configuration for iscsi hba
> >
> >
> > On Thu, 2009-02-05 at 14:33 -0800, Karen Xie wrote:
> > > -Original Message-
> > > From: open-iscsi@googlegroups.com
> [mailto:open-is...@googlegroups.com]
> > > On Behalf Of Anil Veerabhadrappa
> > > Sent: Thursday, February 05, 2009 11:23 AM
> > > To: open-iscsi@googlegroups.com; micha...@cs.wisc.edu
> > > Cc: mchri...@redhat.com; mc...@broadcom.com; be...@broadcom.com;
> > > ani...@broadcom.com
> > > Subject: [RFC] : network configuration for iscsi hba
> > >
> > >
> > > Hi,
> > >
> > >We'd like to propose a general scheme for configuring network
> > > parameters (IP address/mask/DHCP, etc) for iSCSI NICs that use a
> > private
> > > IP address. The current scheme of using sysfs is not very good
> because
> > > bootproto, IP address, netmask, VLAN ID, etc all need to be set
> > > together. Having separate sysfs entries and updating them separately
> > and
> > > independently will not work. Putting everything in a netlink message
> > > seems to be a better solution. After weighing different solutions,
> we
> > > feel expanding existing netlink family, NETLINK_ISCSI between iscsid
> > and
> > > scsi_transport_iscsi is a flexible solution which allows information
> > > flow to be initiated from either side. Also this solution is
> flexible
> > > and elegantly handles network devices with multiple IP addresses.
> > >
> > >The objective of this proposal is to make this interface common
> for
> > > all iscsi offload solutions supported by open-iscsi. We would like
> to
> > > hear comments and suggestions from other iscsi offload vendors in
> > > defining this interface.
> > >
> > > Regards,
> > > Anil Veerabhadrappa
> > >
> > >
> > > Proposal to add netlink message type:
> > > -
> > > 3 new netlink message types are required to support network
> config
> > > message exchange between user and kernel components,
> > > 1. ISCSI_UEVENT_SET_NET_CONFIG - push iface info to driver to
> > > configure
> > > an iscsi network interface
> > > 2. ISCSI_UEVENT_GET_NET_CONFIG - get MAC address list, etc'
> > > 3. ISCSI_KEVENT_NET_CONFIG - propagate attribute changes
> > > from
> > > adapter to iscsid (e.g. advertise newly obtained dhcp address)
> > >
> > > iscsid will use this netlink messages to pass network
> > configuration
> > > between user mode application and the driver. Once this message is
> > > received by scsi_transport_iscsi module it will call driver's newly
> > > added callback handlers in the iscsi_transport structure(net_config
> &
> > > get_net_config) and also broadcast netlink message back to any
> > hardware
> > > vendor's user level daemons
> > >
> > >
> > > ISCSI_XEVENT_NET_CONFIG message payload format:
> > > ---
> > > Payload consists of one or more config parameters defined in TLV
> > > (Type - Length - Value) format.
> > >
> > > struct net_cfg_tlv {
> > > uint32_t type;
> > > uint32_t length;
> > > uint8_t value[0];
> > > };
> > >
> > >
> > > Message types:
> > > --
> > > This interface is envisioned to support standard netw
RE: [RFC] : network configuration for iscsi hba
If it is dhcp, does the dhcp server settings need to be provided? Or it
is going to be handled outside of iscsi?
Also a question about the set_net_config, suppose a list of parameters
are send down, if one or more values are not supported, does the
operation marked as fail and the user has re-do the iface file (to edit
out the unsupported values)?
Thanks,
Karen
-Original Message-
From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
On Behalf Of Anil Veerabhadrappa
Sent: Thursday, February 05, 2009 4:21 PM
To: open-iscsi@googlegroups.com
Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin Li
Subject: RE: [RFC] : network configuration for iscsi hba
On Thu, 2009-02-05 at 16:00 -0800, Karen Xie wrote:
> Thanks,
> What are the possible values of "ISCSI_NET_CFG_BOOTPROTO"?
>
static and dhcp
> Karen
>
> -Original Message-
> From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
> On Behalf Of Anil Veerabhadrappa
> Sent: Thursday, February 05, 2009 3:23 PM
> To: open-iscsi@googlegroups.com
> Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin
Li
> Subject: RE: [RFC] : network configuration for iscsi hba
>
>
> On Thu, 2009-02-05 at 14:33 -0800, Karen Xie wrote:
> > -Original Message-
> > From: open-iscsi@googlegroups.com
[mailto:open-is...@googlegroups.com]
> > On Behalf Of Anil Veerabhadrappa
> > Sent: Thursday, February 05, 2009 11:23 AM
> > To: open-iscsi@googlegroups.com; micha...@cs.wisc.edu
> > Cc: mchri...@redhat.com; mc...@broadcom.com; be...@broadcom.com;
> > ani...@broadcom.com
> > Subject: [RFC] : network configuration for iscsi hba
> >
> >
> > Hi,
> >
> >We'd like to propose a general scheme for configuring network
> > parameters (IP address/mask/DHCP, etc) for iSCSI NICs that use a
> private
> > IP address. The current scheme of using sysfs is not very good
because
> > bootproto, IP address, netmask, VLAN ID, etc all need to be set
> > together. Having separate sysfs entries and updating them separately
> and
> > independently will not work. Putting everything in a netlink message
> > seems to be a better solution. After weighing different solutions,
we
> > feel expanding existing netlink family, NETLINK_ISCSI between iscsid
> and
> > scsi_transport_iscsi is a flexible solution which allows information
> > flow to be initiated from either side. Also this solution is
flexible
> > and elegantly handles network devices with multiple IP addresses.
> >
> >The objective of this proposal is to make this interface common
for
> > all iscsi offload solutions supported by open-iscsi. We would like
to
> > hear comments and suggestions from other iscsi offload vendors in
> > defining this interface.
> >
> > Regards,
> > Anil Veerabhadrappa
> >
> >
> > Proposal to add netlink message type:
> > -
> > 3 new netlink message types are required to support network
config
> > message exchange between user and kernel components,
> > 1. ISCSI_UEVENT_SET_NET_CONFIG - push iface info to driver to
> > configure
> > an iscsi network interface
> > 2. ISCSI_UEVENT_GET_NET_CONFIG - get MAC address list, etc'
> > 3. ISCSI_KEVENT_NET_CONFIG - propagate attribute changes
> > from
> > adapter to iscsid (e.g. advertise newly obtained dhcp address)
> >
> > iscsid will use this netlink messages to pass network
> configuration
> > between user mode application and the driver. Once this message is
> > received by scsi_transport_iscsi module it will call driver's newly
> > added callback handlers in the iscsi_transport structure(net_config
&
> > get_net_config) and also broadcast netlink message back to any
> hardware
> > vendor's user level daemons
> >
> >
> > ISCSI_XEVENT_NET_CONFIG message payload format:
> > ---
> > Payload consists of one or more config parameters defined in TLV
> > (Type - Length - Value) format.
> >
> > struct net_cfg_tlv {
> > uint32_t type;
> > uint32_t length;
> > uint8_t value[0];
> > };
> >
> >
> > Message types:
> > --
> > This interface is envisioned to support standard network
> parameters
> > such as netdev name, MAC address, IPv4/IPv6 address, VLAN, boot
> protocol
> > (static or dhcp), etc'. Please refer to 'net_cfg_e' in proposed
header
> > file changes below.
> >
> >
> > Advantages:
> > ---
> > This approach is much cleaner and delinks network configuration
> > parameters currently bound to host attributes. Old scheme actually
> > breaks the layering scheme as seen below,
> >
> >SCSI (net config parametes currently resides here)
> > |
> >iSCSI
> > |
> > TCP/IP
> >
> > This new approach is a deviation from current host attributes
> > approach and places emphasis in iface components of iscsid and the
> LLD.
> >
> >
> > Changes to iscsi transport headers:
> > ---
> >
RE: [RFC] : network configuration for iscsi hba
On Thu, 2009-02-05 at 16:00 -0800, Karen Xie wrote:
> Thanks,
> What are the possible values of "ISCSI_NET_CFG_BOOTPROTO"?
>
static and dhcp
> Karen
>
> -Original Message-
> From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
> On Behalf Of Anil Veerabhadrappa
> Sent: Thursday, February 05, 2009 3:23 PM
> To: open-iscsi@googlegroups.com
> Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin Li
> Subject: RE: [RFC] : network configuration for iscsi hba
>
>
> On Thu, 2009-02-05 at 14:33 -0800, Karen Xie wrote:
> > -Original Message-
> > From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
> > On Behalf Of Anil Veerabhadrappa
> > Sent: Thursday, February 05, 2009 11:23 AM
> > To: open-iscsi@googlegroups.com; micha...@cs.wisc.edu
> > Cc: mchri...@redhat.com; mc...@broadcom.com; be...@broadcom.com;
> > ani...@broadcom.com
> > Subject: [RFC] : network configuration for iscsi hba
> >
> >
> > Hi,
> >
> >We'd like to propose a general scheme for configuring network
> > parameters (IP address/mask/DHCP, etc) for iSCSI NICs that use a
> private
> > IP address. The current scheme of using sysfs is not very good because
> > bootproto, IP address, netmask, VLAN ID, etc all need to be set
> > together. Having separate sysfs entries and updating them separately
> and
> > independently will not work. Putting everything in a netlink message
> > seems to be a better solution. After weighing different solutions, we
> > feel expanding existing netlink family, NETLINK_ISCSI between iscsid
> and
> > scsi_transport_iscsi is a flexible solution which allows information
> > flow to be initiated from either side. Also this solution is flexible
> > and elegantly handles network devices with multiple IP addresses.
> >
> >The objective of this proposal is to make this interface common for
> > all iscsi offload solutions supported by open-iscsi. We would like to
> > hear comments and suggestions from other iscsi offload vendors in
> > defining this interface.
> >
> > Regards,
> > Anil Veerabhadrappa
> >
> >
> > Proposal to add netlink message type:
> > -
> > 3 new netlink message types are required to support network config
> > message exchange between user and kernel components,
> > 1. ISCSI_UEVENT_SET_NET_CONFIG - push iface info to driver to
> > configure
> > an iscsi network interface
> > 2. ISCSI_UEVENT_GET_NET_CONFIG - get MAC address list, etc'
> > 3. ISCSI_KEVENT_NET_CONFIG - propagate attribute changes
> > from
> > adapter to iscsid (e.g. advertise newly obtained dhcp address)
> >
> > iscsid will use this netlink messages to pass network
> configuration
> > between user mode application and the driver. Once this message is
> > received by scsi_transport_iscsi module it will call driver's newly
> > added callback handlers in the iscsi_transport structure(net_config &
> > get_net_config) and also broadcast netlink message back to any
> hardware
> > vendor's user level daemons
> >
> >
> > ISCSI_XEVENT_NET_CONFIG message payload format:
> > ---
> > Payload consists of one or more config parameters defined in TLV
> > (Type - Length - Value) format.
> >
> > struct net_cfg_tlv {
> > uint32_t type;
> > uint32_t length;
> > uint8_t value[0];
> > };
> >
> >
> > Message types:
> > --
> > This interface is envisioned to support standard network
> parameters
> > such as netdev name, MAC address, IPv4/IPv6 address, VLAN, boot
> protocol
> > (static or dhcp), etc'. Please refer to 'net_cfg_e' in proposed header
> > file changes below.
> >
> >
> > Advantages:
> > ---
> > This approach is much cleaner and delinks network configuration
> > parameters currently bound to host attributes. Old scheme actually
> > breaks the layering scheme as seen below,
> >
> >SCSI (net config parametes currently resides here)
> > |
> >iSCSI
> > |
> > TCP/IP
> >
> > This new approach is a deviation from current host attributes
> > approach and places emphasis in iface components of iscsid and the
> LLD.
> >
> >
> > Changes to iscsi transport headers:
> > ---
> >
> > diff --git a/include/iscsi_if.h b/include/iscsi_if.h
> > index afa86e8..76eea8c 100644
> > --- a/include/iscsi_if.h
> > +++ b/include/iscsi_if.h
> > @@ -51,6 +51,8 @@ enum iscsi_uevent_e {
> > ISCSI_UEVENT_SET_HOST_PARAM = UEVENT_BASE + 16,
> > ISCSI_UEVENT_UNBIND_SESSION = UEVENT_BASE + 17,
> > ISCSI_UEVENT_CREATE_BOUND_SESSION = UEVENT_BASE + 18,
> > + ISCSI_UEVENT_SET_NET_CONFIG = UEVENT_BASE + 19,
> > + ISCSI_UEVENT_GET_NET_CONFIG = UEVENT_BASE + 20,
> >
> > /* up events */
> > ISCSI_KEVENT_RECV_PDU = KEVENT_BASE + 1,
> > @@ -59,6 +61,7 @@ enum iscsi_uevent_e {
> > ISCSI_KEVENT_DESTROY_SESSION
RE: [RFC] : network configuration for iscsi hba
Thanks,
What are the possible values of "ISCSI_NET_CFG_BOOTPROTO"?
Karen
-Original Message-
From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
On Behalf Of Anil Veerabhadrappa
Sent: Thursday, February 05, 2009 3:23 PM
To: open-iscsi@googlegroups.com
Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin Li
Subject: RE: [RFC] : network configuration for iscsi hba
On Thu, 2009-02-05 at 14:33 -0800, Karen Xie wrote:
> -Original Message-
> From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
> On Behalf Of Anil Veerabhadrappa
> Sent: Thursday, February 05, 2009 11:23 AM
> To: open-iscsi@googlegroups.com; micha...@cs.wisc.edu
> Cc: mchri...@redhat.com; mc...@broadcom.com; be...@broadcom.com;
> ani...@broadcom.com
> Subject: [RFC] : network configuration for iscsi hba
>
>
> Hi,
>
>We'd like to propose a general scheme for configuring network
> parameters (IP address/mask/DHCP, etc) for iSCSI NICs that use a
private
> IP address. The current scheme of using sysfs is not very good because
> bootproto, IP address, netmask, VLAN ID, etc all need to be set
> together. Having separate sysfs entries and updating them separately
and
> independently will not work. Putting everything in a netlink message
> seems to be a better solution. After weighing different solutions, we
> feel expanding existing netlink family, NETLINK_ISCSI between iscsid
and
> scsi_transport_iscsi is a flexible solution which allows information
> flow to be initiated from either side. Also this solution is flexible
> and elegantly handles network devices with multiple IP addresses.
>
>The objective of this proposal is to make this interface common for
> all iscsi offload solutions supported by open-iscsi. We would like to
> hear comments and suggestions from other iscsi offload vendors in
> defining this interface.
>
> Regards,
> Anil Veerabhadrappa
>
>
> Proposal to add netlink message type:
> -
> 3 new netlink message types are required to support network config
> message exchange between user and kernel components,
> 1. ISCSI_UEVENT_SET_NET_CONFIG - push iface info to driver to
> configure
> an iscsi network interface
> 2. ISCSI_UEVENT_GET_NET_CONFIG - get MAC address list, etc'
> 3. ISCSI_KEVENT_NET_CONFIG - propagate attribute changes
> from
> adapter to iscsid (e.g. advertise newly obtained dhcp address)
>
> iscsid will use this netlink messages to pass network
configuration
> between user mode application and the driver. Once this message is
> received by scsi_transport_iscsi module it will call driver's newly
> added callback handlers in the iscsi_transport structure(net_config &
> get_net_config) and also broadcast netlink message back to any
hardware
> vendor's user level daemons
>
>
> ISCSI_XEVENT_NET_CONFIG message payload format:
> ---
> Payload consists of one or more config parameters defined in TLV
> (Type - Length - Value) format.
>
> struct net_cfg_tlv {
> uint32_t type;
> uint32_t length;
> uint8_t value[0];
> };
>
>
> Message types:
> --
> This interface is envisioned to support standard network
parameters
> such as netdev name, MAC address, IPv4/IPv6 address, VLAN, boot
protocol
> (static or dhcp), etc'. Please refer to 'net_cfg_e' in proposed header
> file changes below.
>
>
> Advantages:
> ---
> This approach is much cleaner and delinks network configuration
> parameters currently bound to host attributes. Old scheme actually
> breaks the layering scheme as seen below,
>
>SCSI (net config parametes currently resides here)
> |
>iSCSI
> |
> TCP/IP
>
> This new approach is a deviation from current host attributes
> approach and places emphasis in iface components of iscsid and the
LLD.
>
>
> Changes to iscsi transport headers:
> ---
>
> diff --git a/include/iscsi_if.h b/include/iscsi_if.h
> index afa86e8..76eea8c 100644
> --- a/include/iscsi_if.h
> +++ b/include/iscsi_if.h
> @@ -51,6 +51,8 @@ enum iscsi_uevent_e {
> ISCSI_UEVENT_SET_HOST_PARAM = UEVENT_BASE + 16,
> ISCSI_UEVENT_UNBIND_SESSION = UEVENT_BASE + 17,
> ISCSI_UEVENT_CREATE_BOUND_SESSION = UEVENT_BASE + 18,
> + ISCSI_UEVENT_SET_NET_CONFIG = UEVENT_BASE + 19,
> + ISCSI_UEVENT_GET_NET_CONFIG = UEVENT_BASE + 20,
>
> /* up events */
> ISCSI_KEVENT_RECV_PDU = KEVENT_BASE + 1,
> @@ -59,6 +61,7 @@ enum iscsi_uevent_e {
> ISCSI_KEVENT_DESTROY_SESSION= KEVENT_BASE + 4,
> ISCSI_KEVENT_UNBIND_SESSION = KEVENT_BASE + 5,
> ISCSI_KEVENT_CREATE_SESSION = KEVENT_BASE + 6,
> + ISCSI_KEVENT_NET_CONFIG = KEVENT_BASE + 7,
> };
>
> enum iscsi_tgt_dscvr {
> @@ -317,6 +320,42 @@ enum iscsi_host_param {
> #define ISCSI_HOST_NETDEV
RE: [RFC] : network configuration for iscsi hba
On Thu, 2009-02-05 at 14:33 -0800, Karen Xie wrote:
> -Original Message-
> From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
> On Behalf Of Anil Veerabhadrappa
> Sent: Thursday, February 05, 2009 11:23 AM
> To: open-iscsi@googlegroups.com; micha...@cs.wisc.edu
> Cc: mchri...@redhat.com; mc...@broadcom.com; be...@broadcom.com;
> ani...@broadcom.com
> Subject: [RFC] : network configuration for iscsi hba
>
>
> Hi,
>
>We'd like to propose a general scheme for configuring network
> parameters (IP address/mask/DHCP, etc) for iSCSI NICs that use a private
> IP address. The current scheme of using sysfs is not very good because
> bootproto, IP address, netmask, VLAN ID, etc all need to be set
> together. Having separate sysfs entries and updating them separately and
> independently will not work. Putting everything in a netlink message
> seems to be a better solution. After weighing different solutions, we
> feel expanding existing netlink family, NETLINK_ISCSI between iscsid and
> scsi_transport_iscsi is a flexible solution which allows information
> flow to be initiated from either side. Also this solution is flexible
> and elegantly handles network devices with multiple IP addresses.
>
>The objective of this proposal is to make this interface common for
> all iscsi offload solutions supported by open-iscsi. We would like to
> hear comments and suggestions from other iscsi offload vendors in
> defining this interface.
>
> Regards,
> Anil Veerabhadrappa
>
>
> Proposal to add netlink message type:
> -
> 3 new netlink message types are required to support network config
> message exchange between user and kernel components,
> 1. ISCSI_UEVENT_SET_NET_CONFIG - push iface info to driver to
> configure
> an iscsi network interface
> 2. ISCSI_UEVENT_GET_NET_CONFIG - get MAC address list, etc'
> 3. ISCSI_KEVENT_NET_CONFIG - propagate attribute changes
> from
> adapter to iscsid (e.g. advertise newly obtained dhcp address)
>
> iscsid will use this netlink messages to pass network configuration
> between user mode application and the driver. Once this message is
> received by scsi_transport_iscsi module it will call driver's newly
> added callback handlers in the iscsi_transport structure(net_config &
> get_net_config) and also broadcast netlink message back to any hardware
> vendor's user level daemons
>
>
> ISCSI_XEVENT_NET_CONFIG message payload format:
> ---
> Payload consists of one or more config parameters defined in TLV
> (Type - Length - Value) format.
>
> struct net_cfg_tlv {
> uint32_t type;
> uint32_t length;
> uint8_t value[0];
> };
>
>
> Message types:
> --
> This interface is envisioned to support standard network parameters
> such as netdev name, MAC address, IPv4/IPv6 address, VLAN, boot protocol
> (static or dhcp), etc'. Please refer to 'net_cfg_e' in proposed header
> file changes below.
>
>
> Advantages:
> ---
> This approach is much cleaner and delinks network configuration
> parameters currently bound to host attributes. Old scheme actually
> breaks the layering scheme as seen below,
>
>SCSI (net config parametes currently resides here)
> |
>iSCSI
> |
> TCP/IP
>
> This new approach is a deviation from current host attributes
> approach and places emphasis in iface components of iscsid and the LLD.
>
>
> Changes to iscsi transport headers:
> ---
>
> diff --git a/include/iscsi_if.h b/include/iscsi_if.h
> index afa86e8..76eea8c 100644
> --- a/include/iscsi_if.h
> +++ b/include/iscsi_if.h
> @@ -51,6 +51,8 @@ enum iscsi_uevent_e {
> ISCSI_UEVENT_SET_HOST_PARAM = UEVENT_BASE + 16,
> ISCSI_UEVENT_UNBIND_SESSION = UEVENT_BASE + 17,
> ISCSI_UEVENT_CREATE_BOUND_SESSION = UEVENT_BASE + 18,
> + ISCSI_UEVENT_SET_NET_CONFIG = UEVENT_BASE + 19,
> + ISCSI_UEVENT_GET_NET_CONFIG = UEVENT_BASE + 20,
>
> /* up events */
> ISCSI_KEVENT_RECV_PDU = KEVENT_BASE + 1,
> @@ -59,6 +61,7 @@ enum iscsi_uevent_e {
> ISCSI_KEVENT_DESTROY_SESSION= KEVENT_BASE + 4,
> ISCSI_KEVENT_UNBIND_SESSION = KEVENT_BASE + 5,
> ISCSI_KEVENT_CREATE_SESSION = KEVENT_BASE + 6,
> + ISCSI_KEVENT_NET_CONFIG = KEVENT_BASE + 7,
> };
>
> enum iscsi_tgt_dscvr {
> @@ -317,6 +320,42 @@ enum iscsi_host_param {
> #define ISCSI_HOST_NETDEV_NAME (1ULL <<
> ISCSI_HOST_PARAM_NETDEV_NAME)
> #define ISCSI_HOST_IPADDRESS (1ULL <<
> ISCSI_HOST_PARAM_IPADDRESS)
>
> +/* iscsi network stack parameters */
> +enum iscsi_net_cfg_e {
> + ISCSI_NET_CFG_UNKNOWN 0x00,
> +
> + ISCSI_NET_CFG_NETDEV_NAME ISCSI_NET_CFG_UNKNOWN +
> 1,
> + ISCSI_NET_CFG_MAC_ADDR ISCSI_NET_CFG_UNKNO
Re: [PATCH] iscsi tcp: bidi capable
Boaz Harrosh wrote:
> From: Pete Wyckoff
>
> Mark iscsi_tcp as being capable of bidirectional transfers. The
> bsg interface checks this bit before attempting any bidirectional
> commands.
>
> Signed-off-by: Pete Wyckoff
> Signed-off-by: Boaz Harrosh
> ---
> drivers/scsi/iscsi_tcp.c |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
> index af092a8..9e2d4fb 100644
> --- a/drivers/scsi/iscsi_tcp.c
> +++ b/drivers/scsi/iscsi_tcp.c
> @@ -806,6 +806,12 @@ static void iscsi_sw_tcp_session_destroy(struct
> iscsi_cls_session *cls_session)
> iscsi_host_free(shost);
> }
>
> +static int iscsi_tcp_slave_alloc(struct scsi_device *sdev)
> +{
I merged this for 2.6.30 with a small change where this is renamed
iscsi_sw_tcp_slave_alloc to fit the naming of functions in that file.
Thanks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-iscsi@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
-~--~~~~--~~--~--~---
RE: [PATCH 2.6.29 1/1] cxgb3i - more transmit work-request checks
Thanks, Mike, I will re-submit the patch against scsi-rc-fixes. This one was based on scsi-misc-2.6/linux-2.6-iscsi. Karen -Original Message- From: Mike Christie [mailto:micha...@cs.wisc.edu] Sent: Thursday, February 05, 2009 1:43 PM To: Karen Xie Cc: open-iscsi@googlegroups.com; linux-s...@vger.kernel.org; james.bottom...@hansenpartnership.com Subject: Re: [PATCH 2.6.29 1/1] cxgb3i - more transmit work-request checks Karen Xie wrote: > [PATCH 2.6.29 1/1] cxgb3i - more transmit work-request checks > > From: Karen Xie > > - added more checkings for transmit work-request. > - reserve one work-request for credit return. > - stop queueing up the outgoing pdus if transmit window is full. > - split the skb cb into tx and rx portion > What kernel was this made against? I think the patch might include some changes that already went upstream. You might want to rebase the patch against scsi-rc-fixes. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@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 -~--~~~~--~~--~--~---
RE: [RFC] : network configuration for iscsi hba
-Original Message-
From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
On Behalf Of Anil Veerabhadrappa
Sent: Thursday, February 05, 2009 11:23 AM
To: open-iscsi@googlegroups.com; micha...@cs.wisc.edu
Cc: mchri...@redhat.com; mc...@broadcom.com; be...@broadcom.com;
ani...@broadcom.com
Subject: [RFC] : network configuration for iscsi hba
Hi,
We'd like to propose a general scheme for configuring network
parameters (IP address/mask/DHCP, etc) for iSCSI NICs that use a private
IP address. The current scheme of using sysfs is not very good because
bootproto, IP address, netmask, VLAN ID, etc all need to be set
together. Having separate sysfs entries and updating them separately and
independently will not work. Putting everything in a netlink message
seems to be a better solution. After weighing different solutions, we
feel expanding existing netlink family, NETLINK_ISCSI between iscsid and
scsi_transport_iscsi is a flexible solution which allows information
flow to be initiated from either side. Also this solution is flexible
and elegantly handles network devices with multiple IP addresses.
The objective of this proposal is to make this interface common for
all iscsi offload solutions supported by open-iscsi. We would like to
hear comments and suggestions from other iscsi offload vendors in
defining this interface.
Regards,
Anil Veerabhadrappa
Proposal to add netlink message type:
-
3 new netlink message types are required to support network config
message exchange between user and kernel components,
1. ISCSI_UEVENT_SET_NET_CONFIG - push iface info to driver to
configure
an iscsi network interface
2. ISCSI_UEVENT_GET_NET_CONFIG - get MAC address list, etc'
3. ISCSI_KEVENT_NET_CONFIG - propagate attribute changes
from
adapter to iscsid (e.g. advertise newly obtained dhcp address)
iscsid will use this netlink messages to pass network configuration
between user mode application and the driver. Once this message is
received by scsi_transport_iscsi module it will call driver's newly
added callback handlers in the iscsi_transport structure(net_config &
get_net_config) and also broadcast netlink message back to any hardware
vendor's user level daemons
ISCSI_XEVENT_NET_CONFIG message payload format:
---
Payload consists of one or more config parameters defined in TLV
(Type - Length - Value) format.
struct net_cfg_tlv {
uint32_t type;
uint32_t length;
uint8_t value[0];
};
Message types:
--
This interface is envisioned to support standard network parameters
such as netdev name, MAC address, IPv4/IPv6 address, VLAN, boot protocol
(static or dhcp), etc'. Please refer to 'net_cfg_e' in proposed header
file changes below.
Advantages:
---
This approach is much cleaner and delinks network configuration
parameters currently bound to host attributes. Old scheme actually
breaks the layering scheme as seen below,
SCSI (net config parametes currently resides here)
|
iSCSI
|
TCP/IP
This new approach is a deviation from current host attributes
approach and places emphasis in iface components of iscsid and the LLD.
Changes to iscsi transport headers:
---
diff --git a/include/iscsi_if.h b/include/iscsi_if.h
index afa86e8..76eea8c 100644
--- a/include/iscsi_if.h
+++ b/include/iscsi_if.h
@@ -51,6 +51,8 @@ enum iscsi_uevent_e {
ISCSI_UEVENT_SET_HOST_PARAM = UEVENT_BASE + 16,
ISCSI_UEVENT_UNBIND_SESSION = UEVENT_BASE + 17,
ISCSI_UEVENT_CREATE_BOUND_SESSION = UEVENT_BASE + 18,
+ ISCSI_UEVENT_SET_NET_CONFIG = UEVENT_BASE + 19,
+ ISCSI_UEVENT_GET_NET_CONFIG = UEVENT_BASE + 20,
/* up events */
ISCSI_KEVENT_RECV_PDU = KEVENT_BASE + 1,
@@ -59,6 +61,7 @@ enum iscsi_uevent_e {
ISCSI_KEVENT_DESTROY_SESSION= KEVENT_BASE + 4,
ISCSI_KEVENT_UNBIND_SESSION = KEVENT_BASE + 5,
ISCSI_KEVENT_CREATE_SESSION = KEVENT_BASE + 6,
+ ISCSI_KEVENT_NET_CONFIG = KEVENT_BASE + 7,
};
enum iscsi_tgt_dscvr {
@@ -317,6 +320,42 @@ enum iscsi_host_param {
#define ISCSI_HOST_NETDEV_NAME (1ULL <<
ISCSI_HOST_PARAM_NETDEV_NAME)
#define ISCSI_HOST_IPADDRESS (1ULL <<
ISCSI_HOST_PARAM_IPADDRESS)
+/* iscsi network stack parameters */
+enum iscsi_net_cfg_e {
+ ISCSI_NET_CFG_UNKNOWN 0x00,
+
+ ISCSI_NET_CFG_NETDEV_NAME ISCSI_NET_CFG_UNKNOWN +
1,
+ ISCSI_NET_CFG_MAC_ADDR ISCSI_NET_CFG_UNKNOWN +
2,
+ ISCSI_NET_CFG_IPV4_ADDR ISCSI_NET_CFG_UNKNOWN +
3,
+ ISCSI_NET_CFG_IPV6_ADDR ISCSI_NET_CFG_UNKNOWN +
4,
+ ISCSI_NET_CFG_IPV4_NETMASK ISCSI_NET_CFG_UNKNOWN +
5,
+ ISCSI_NET_CFG_IPV6_NETMASK
Re: [PATCH 2.6.29 1/1] cxgb3i - more transmit work-request checks
Karen Xie wrote: > [PATCH 2.6.29 1/1] cxgb3i - more transmit work-request checks > > From: Karen Xie > > - added more checkings for transmit work-request. > - reserve one work-request for credit return. > - stop queueing up the outgoing pdus if transmit window is full. > - split the skb cb into tx and rx portion > What kernel was this made against? I think the patch might include some changes that already went upstream. You might want to rebase the patch against scsi-rc-fixes. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@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 -~--~~~~--~~--~--~---
[RFC] : network configuration for iscsi hba
Hi,
We'd like to propose a general scheme for configuring network
parameters (IP address/mask/DHCP, etc) for iSCSI NICs that use a private
IP address. The current scheme of using sysfs is not very good because
bootproto, IP address, netmask, VLAN ID, etc all need to be set
together. Having separate sysfs entries and updating them separately and
independently will not work. Putting everything in a netlink message
seems to be a better solution. After weighing different solutions, we
feel expanding existing netlink family, NETLINK_ISCSI between iscsid and
scsi_transport_iscsi is a flexible solution which allows information
flow to be initiated from either side. Also this solution is flexible
and elegantly handles network devices with multiple IP addresses.
The objective of this proposal is to make this interface common for
all iscsi offload solutions supported by open-iscsi. We would like to
hear comments and suggestions from other iscsi offload vendors in
defining this interface.
Regards,
Anil Veerabhadrappa
Proposal to add netlink message type:
-
3 new netlink message types are required to support network config
message exchange between user and kernel components,
1. ISCSI_UEVENT_SET_NET_CONFIG - push iface info to driver to configure
an iscsi network interface
2. ISCSI_UEVENT_GET_NET_CONFIG - get MAC address list, etc'
3. ISCSI_KEVENT_NET_CONFIG - propagate attribute changes from
adapter to iscsid (e.g. advertise newly obtained dhcp address)
iscsid will use this netlink messages to pass network configuration
between user mode application and the driver. Once this message is
received by scsi_transport_iscsi module it will call driver's newly
added callback handlers in the iscsi_transport structure(net_config &
get_net_config) and also broadcast netlink message back to any hardware
vendor's user level daemons
ISCSI_XEVENT_NET_CONFIG message payload format:
---
Payload consists of one or more config parameters defined in TLV
(Type - Length - Value) format.
struct net_cfg_tlv {
uint32_t type;
uint32_t length;
uint8_t value[0];
};
Message types:
--
This interface is envisioned to support standard network parameters
such as netdev name, MAC address, IPv4/IPv6 address, VLAN, boot protocol
(static or dhcp), etc'. Please refer to 'net_cfg_e' in proposed header
file changes below.
Advantages:
---
This approach is much cleaner and delinks network configuration
parameters currently bound to host attributes. Old scheme actually
breaks the layering scheme as seen below,
SCSI (net config parametes currently resides here)
|
iSCSI
|
TCP/IP
This new approach is a deviation from current host attributes
approach and places emphasis in iface components of iscsid and the LLD.
Changes to iscsi transport headers:
---
diff --git a/include/iscsi_if.h b/include/iscsi_if.h
index afa86e8..76eea8c 100644
--- a/include/iscsi_if.h
+++ b/include/iscsi_if.h
@@ -51,6 +51,8 @@ enum iscsi_uevent_e {
ISCSI_UEVENT_SET_HOST_PARAM = UEVENT_BASE + 16,
ISCSI_UEVENT_UNBIND_SESSION = UEVENT_BASE + 17,
ISCSI_UEVENT_CREATE_BOUND_SESSION = UEVENT_BASE + 18,
+ ISCSI_UEVENT_SET_NET_CONFIG = UEVENT_BASE + 19,
+ ISCSI_UEVENT_GET_NET_CONFIG = UEVENT_BASE + 20,
/* up events */
ISCSI_KEVENT_RECV_PDU = KEVENT_BASE + 1,
@@ -59,6 +61,7 @@ enum iscsi_uevent_e {
ISCSI_KEVENT_DESTROY_SESSION= KEVENT_BASE + 4,
ISCSI_KEVENT_UNBIND_SESSION = KEVENT_BASE + 5,
ISCSI_KEVENT_CREATE_SESSION = KEVENT_BASE + 6,
+ ISCSI_KEVENT_NET_CONFIG = KEVENT_BASE + 7,
};
enum iscsi_tgt_dscvr {
@@ -317,6 +320,42 @@ enum iscsi_host_param {
#define ISCSI_HOST_NETDEV_NAME (1ULL << ISCSI_HOST_PARAM_NETDEV_NAME)
#define ISCSI_HOST_IPADDRESS (1ULL << ISCSI_HOST_PARAM_IPADDRESS)
+/* iscsi network stack parameters */
+enum iscsi_net_cfg_e {
+ ISCSI_NET_CFG_UNKNOWN 0x00,
+
+ ISCSI_NET_CFG_NETDEV_NAME ISCSI_NET_CFG_UNKNOWN + 1,
+ ISCSI_NET_CFG_MAC_ADDR ISCSI_NET_CFG_UNKNOWN + 2,
+ ISCSI_NET_CFG_IPV4_ADDR ISCSI_NET_CFG_UNKNOWN + 3,
+ ISCSI_NET_CFG_IPV6_ADDR ISCSI_NET_CFG_UNKNOWN + 4,
+ ISCSI_NET_CFG_IPV4_NETMASK ISCSI_NET_CFG_UNKNOWN + 5,
+ ISCSI_NET_CFG_IPV6_NETMASK ISCSI_NET_CFG_UNKNOWN + 6,
+ ISCSI_NET_CFG_IPV4_GATEWAY ISCSI_NET_CFG_UNKNOWN + 7,
+ ISCSI_NET_CFG_IPV6_GATEWAY ISCSI_NET_CFG_UNKNOWN + 8,
+ ISCSI_NET_CFG_BOOTPROTO ISCSI_NET_CFG_UNKNOWN + 9,
+ ISCSI_NET_CFG_IPV6_AUTO_CFG ISCSI_NET_CFG_UNKNOWN + 10,
+ ISCSI_NET_CFG_MTU
Re: EqualLogic load-balancing logout/re-login behavior (asynchrounous event logout)
Mike Christie wrote: > Konrad Rzeszutek wrote: >> In the 2.0-865 version when we received a ISCSI_ASYNC_MSG_REQUEST_LOGOUT we >> would >> logout, and then retry logging back in: >> >> - <28>Jul 28 20:15:40 iscsid: Target requests logout within 3 seconds for >> connection^M >> - <28>Jul 28 20:15:45 iscsid: connection5:0 is operational after recovery (2 >> attempts)^M >> >> And we would have a short hiccup (5 seconds) of the connection being gone. >> >> This as my understanding was a mechanism for the EqualLogic box to "move" >> (re-establishing >> allegiance) a session to a different port, hence allowing a load-balancing >> mechanism. >> >> In 2.0-869, the git commit 052d014485d2ce5bb7fa8dd0df875dafd1db77df changed >> this >> behavior so that we now actually logout and delete the session. No more >> retries. >> > > > Do you mean the session is destoryed as in the kernel parts are > cleaned/freed up and the iscsid parts are freed? There was a bug in 869 > where the session would get destoryed on some errors it did not in 868, I meant 865. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@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 -~--~~~~--~~--~--~---
Re: EqualLogic load-balancing logout/re-login behavior (asynchrounous event logout)
Konrad Rzeszutek wrote:
> In the 2.0-865 version when we received a ISCSI_ASYNC_MSG_REQUEST_LOGOUT we
> would
> logout, and then retry logging back in:
>
> - <28>Jul 28 20:15:40 iscsid: Target requests logout within 3 seconds for
> connection^M
> - <28>Jul 28 20:15:45 iscsid: connection5:0 is operational after recovery (2
> attempts)^M
>
> And we would have a short hiccup (5 seconds) of the connection being gone.
>
> This as my understanding was a mechanism for the EqualLogic box to "move"
> (re-establishing
> allegiance) a session to a different port, hence allowing a load-balancing
> mechanism.
>
> In 2.0-869, the git commit 052d014485d2ce5bb7fa8dd0df875dafd1db77df changed
> this
> behavior so that we now actually logout and delete the session. No more
> retries.
>
Do you mean the session is destoryed as in the kernel parts are
cleaned/freed up and the iscsid parts are freed? There was a bug in 869
where the session would get destoryed on some errors it did not in 868,
but for 870.2 this is fixed (well we just almost never destroy the session).
> 2.0-865:
> static int iscsi_xmit_mtask(struct iscsi_conn *conn)
> {
> struct iscsi_hdr *hdr = conn->mtask->hdr;
> int rc, was_logout = 0;
>
> spin_unlock_bh(&conn->session->lock);
> if ((hdr->opcode & ISCSI_OPCODE_MASK) == ISCSI_OP_LOGOUT) {
> conn->session->state = ISCSI_STATE_IN_RECOVERY;
> iscsi_block_session(session_to_cls(conn->session));
>
> ...
> 2.0-869:
> static int iscsi_xmit_mtask(struct iscsi_conn *conn)
> {
> struct iscsi_hdr *hdr = conn->mtask->hdr;
> int rc;
>
> if ((hdr->opcode & ISCSI_OPCODE_MASK) == ISCSI_OP_LOGOUT)
> conn->session->state = ISCSI_STATE_LOGGING_OUT;
> spin_unlock_bh(&conn->session->lock);
>
> .. and..
> if (conn->session->state == ISCSI_STATE_LOGGING_OUT) {
> iscsi_free_mgmt_task(conn, conn->mtask);
> conn->mtask = NULL;
> continue;
> }
>
> This comes down to 2.0-869 terminating the session without trying to re-login.
>
What version of 869 are you using? We fixed a problem like this in the
868 test releases for RHEL and it is in upstream (I do not remember the
commit).
I do not think the code you quoted was the problem though, so maybe it
is a different issues (I tried the current code and it worked for me in
870.2). The logout would get sent, then when we clean up the session by
calling stop conn, we should set the session->state to start accepting
commands again:
iscsi_start_session_recovery():
if (flag == STOP_CONN_TERM)
session->state = ISCSI_STATE_TERMINATE;
else if (conn->stop_stage != STOP_CONN_RECOVER)
session->state = ISCSI_STATE_IN_RECOVERY;
So when we go to transmit the login mtask the session->state should not
be logging out anymore.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-iscsi@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
-~--~~~~--~~--~--~---
Mapping Target Name with Device
Hello all, Before I had posted one trouble related to open-iscsi which was sorted with the help of Ross and Lars. I could complete my perl project related to ietadm and open-iscsi . All the information regarding the targets obtained are displayed in a web page. Now my client need to display the size of each targets obtained also. Using the command fdisk -l i can see all the devices available and i have the all the available target names also. How can i map the each target name with the corresponding device ? Waiting for your valuable reply, Praveenzx~ -- # # Praveen~ # # +919895066033 # # --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@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 -~--~~~~--~~--~--~---
