Mike Christie wrote:
I started to do a pseudo patch to see how it would work
With the DHCP thing at hand possibly changing the initiator IP address, I think
what we want to do for iser is use NIC names for ifaces as I do now for
iscsi/tcp with the user taking care of NIC name persistently
Mike Christie wrote:
Ok let me clarify one other thing too. With the network layer we get a
ethX, or whatever you set up your udev rules to use, for each port. That
is what I am saying above represents the device name and port. The iscsi
drivers that interact with the linux net layer like
Mike Christie wrote:
Maybe that is where I am missing your point. One of the reasons for this
is to tell the kernel to ignore the routing rules and use the port we
want. So I was saying if there is no a API to do this then just add one
like someone did for tcp and the socket code.
Mike Christie micha...@cs.wisc.edu wrote:
If the device name and port do not change normally that seems better to
me since it works like the other drivers
just to be on the same page, when you say the other drivers
(=transports) this doesn't include tcp, correct? for the tcp what's
supported
On 03/02/2010 02:42 PM, Or Gerlitz wrote:
Mike Christiemicha...@cs.wisc.edu wrote:
If the device name and port do not change normally that seems better to
me since it works like the other drivers
just to be on the same page, when you say the other drivers
(=transports) this doesn't include
On 03/02/2010 02:42 PM, Or Gerlitz wrote:
As for the IB device name and port number, indeed they don't change
normally, but OTOH the rdma-cm api which iser is using is IP base and
reolves IB local/remote addresses (= GUIDs which relate to
devices/ports) from IP addresses/routing rules and not
On 03/01/2010 02:46 AM, Or Gerlitz wrote:
Mike Christie wrote:
Ah never mind. For some reason I thought you had to have a mask, but if
you give rdma_resolve_addr a addr then it will do the right thing and
use only the port you wanted right?
YES. providing rdma_resolve_addr a source address is
On 03/01/2010 06:29 PM, Mike Christie wrote:
If the device name and port do not change normally that seems better to
me since it works like the other drivers.
Oh yeah, just to be clear, I am saying I prefer above, but that is based
on what I understand today. As I said I did not understand
On 02/25/2010 11:24 PM, Mike Christie wrote:
Do you mean you need a src IP for rdma_resolve_addr? If so, if you have
a src ip, can you override what rdma_resolve_addr gives you for cases
like where you have two ports on the same subnet?
Ah never mind. For some reason I thought you had to have
Mike Christie wrote:
I am fine with either. The netdev name (ethX) also has the same problems
where udev can change it. It is there for aliases or vlans where we
cannot use hwaddress since multiple netdevs have the same MAC.
yes, correct both netdevice name and hwaddress suffer from what you
On 02/25/2010 06:03 AM, Or Gerlitz wrote:
Mike Christie wrote:
I am fine with either. The netdev name (ethX) also has the same problems
where udev can change it. It is there for aliases or vlans where we
cannot use hwaddress since multiple netdevs have the same MAC.
yes, correct both
On 02/25/2010 11:24 PM, Mike Christie wrote:
All in all, when non default interface is needed/used (e.g for
multipathing), I am quite sure we need to have some sort of source ip
for iser in ep_connect, please let me know what you think would be the
easy/best or close to either of (...) way to
Mike Christie wrote:
So is there anything in there that is static and can be used to identify the
port?
With srp you can bind a target to a rnic port, right (from srp_add_port
it looks like the add_target file is on the srp classes rnic port
object)? In userspace for the setup then how do
On 02/24/2010 10:04 AM, Or Gerlitz wrote:
Mike Christie wrote:
So is there anything in there that is static and can be used to identify the
port?
With srp you can bind a target to a rnic port, right (from srp_add_port
it looks like the add_target file is on the srp classes rnic port
Mike Christie wrote:
2. I wasn't sure if there is and if yes what is the transport role in
detecting session failure.
It varies from transport to transport.
For iscsi_tcp we do not really have a nice way to figure out if the
someone just tripped over a cable so that is where the nop comes
On 02/22/2010 09:32 AM, Or Gerlitz wrote:
Mike Christie wrote:
2. I wasn't sure if there is and if yes what is the transport role in
detecting session failure.
It varies from transport to transport.
For iscsi_tcp we do not really have a nice way to figure out if the
someone just tripped over
16 matches
Mail list logo
