[openib-general] [PATCH v2 0/11] [RFC] Support for QLogic Virtual Ethernet I/O Controller (VEx)

Ramachandra Kuchimanchi ramachandra.kuchimanchi at qlogic.com
Thu Nov 16 08:35:46 PST 2006


>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20061116/6f910779/attachment.html>


More information about the general mailing list