Caitlin Bestler wrote:
+int iw_cm_accept(struct iw_cm_id *cm_id,
+ const void *private_data,
+ u8 private_data_len)
+{
{snip}
+ spin_lock_irqsave(&iwcm_id_priv->lock, flags);
+ switch (cm_id->state) {
+ case IW_CM_STATE_CONN_RECV:
+ spin_unlock_irqrestore(&iwcm_id_priv->lock, flags);
+ ret = cm_id->device->iwcm->accept(cm_id, private_data, +
private_data_len); + if (ret == 0) {
+ struct iw_cm_event event;
+ event.event = IW_CM_EVENT_ESTABLISHED;
+ event.provider_id = cm_id->provider_id;
+ event.status = 0;
+ event.local_addr = cm_id->local_addr;
+ event.remote_addr = cm_id->remote_addr;
If the cm_id contains the provider_id, local_addr, and
remote_addr, does it need to be returned as part of the event?
It should be possible to create the cm_id to listen for all
IP addresses that the Ethernet device is capable of accepting.
That would mean that event.local_Addr should be set from the
actual packet.
The cm_id in this case is a new one spawned as a result of receiving a
connection request associated with a listen. The cm_id address information
comes from an event reported by some lower-level entity. I'd need to read back
through more of the code to know where the data comes from, but from an actual
packet is likely.
The question is that if the cm_id contains a copy of the address, then it's not
necessary to also report the same data in the event structure.
This relates back to the question on whether a port has
more than one address. It depends on your definition of a
port. If the definition of a port is a netdevice then it
is only necessary to provide one of the addresses. Existing
techniques allow fetching the other aliases that refer to
the same ethernet interface. There is no reason for the RDMA
drivers to take on the complexity of reporting all possible
IP addresses when the answer already exists in for non-RDMA.
My comment was in reference to the iwcm_port structure, which maps to a physical
port on the device. I can't say that I understand the use of the local_addr
field in that structure.
- Sean
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
