<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7650.28">
<TITLE>RE: [PATCH v2 0/11] [RFC] Support for QLogic Virtual Ethernet I/O Controller (VEx)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>>> If you think these patches are good enough, could you please create a<BR>
>> branch in your git tree based on for-2.6.20 for this code ?<BR>
<BR>
> Yes, I will create a vex branch for this in my tree. However, moving<BR>
> this further upstream will depend on getting a real review of the<BR>
> code, and some sort of protocol document will probably be required for<BR>
> anyone to wade through this...<BR>
><BR>
> - R.<BR>
<BR>
Thanks, Roland. I understand that the code has to go through several rounds<BR>
of review before it is moved upstream.<BR>
<BR>
Would the branch that you create be in sync with the for-2.6.20 branch ?<BR>
That way I can keep the code in sync with the latest changes.<BR>
Also is the branch already created ? I tried to update my copy of the tree<BR>
but could not see a vex branch.<BR>
<BR>
Please note that this driver is a device driver for a remote device and<BR>
the communication between the driver and the device is like any other<BR>
device driver, its just that this driver uses IB as its bus where<BR>
as others use PCI etc.<BR>
<BR>
The entire communication between the driver and VEx can be understood from a<BR>
reading of the code. To make it simpler to understand the code, I am<BR>
providing a small note about the terminology and code organization:<BR>
<BR>
Each virtual NIC has a netpath, which is an abstraction of a connection to<BR>
the VEx. Each netpath has a viport, the virtual port, which is an abstraction<BR>
of the control and data IB connections through which control and data messages<BR>
are exchanged.<BR>
<BR>
The control messages which are exchanged can be seen in<BR>
vnic_control_pkt.h (patch 4). The data messages are nothing but<BR>
transfer of data itself.(patch 5)<BR>
<BR>
The series of functions that are called in viport_statemachine()<BR>
in vnic_viport.c (patch 3) are a good starting point to understand the<BR>
control path. In this, establishment of control and data IB connections<BR>
is done in viport_handle_init_states(). After that, the sequence of request<BR>
and response messages that are exchanged can be seen in<BR>
viport_handle_control_states(), viport_handle_data_states(),<BR>
viport_handle_xchgpool_states(), viport_handle_idle_states() and so on.<BR>
<BR>
The code flow of the driver itself begins when the VEx information is written to the<BR>
sysfs file create_primary. [vnic_create_primary() in vnic_sys.c (patch 8)]<BR>
<BR>
Regards,<BR>
Ram</FONT>
</P>
</BODY>
</HTML>