>> If you think these patches are good enough, could you please create a >> branch in your git tree based on for-2.6.20 for this code ?
> Yes, I will create a vex branch for this in my tree. However, moving > this further upstream will depend on getting a real review of the > code, and some sort of protocol document will probably be required for > anyone to wade through this... > > - R. Thanks, Roland. I understand that the code has to go through several rounds of review before it is moved upstream. Would the branch that you create be in sync with the for-2.6.20 branch ? That way I can keep the code in sync with the latest changes. Also is the branch already created ? I tried to update my copy of the tree but could not see a vex branch. Please note that this driver is a device driver for a remote device and the communication between the driver and the device is like any other device driver, its just that this driver uses IB as its bus where as others use PCI etc. The entire communication between the driver and VEx can be understood from a reading of the code. To make it simpler to understand the code, I am providing a small note about the terminology and code organization: Each virtual NIC has a netpath, which is an abstraction of a connection to the VEx. Each netpath has a viport, the virtual port, which is an abstraction of the control and data IB connections through which control and data messages are exchanged. The control messages which are exchanged can be seen in vnic_control_pkt.h (patch 4). The data messages are nothing but transfer of data itself.(patch 5) The series of functions that are called in viport_statemachine() in vnic_viport.c (patch 3) are a good starting point to understand the control path. In this, establishment of control and data IB connections is done in viport_handle_init_states(). After that, the sequence of request and response messages that are exchanged can be seen in viport_handle_control_states(), viport_handle_data_states(), viport_handle_xchgpool_states(), viport_handle_idle_states() and so on. The code flow of the driver itself begins when the VEx information is written to the sysfs file create_primary. [vnic_create_primary() in vnic_sys.c (patch 8)] Regards, Ram
_______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general