-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
ldmvsw: Make sunvnet_common compatible with ldmvsw
Modify sunvnet common code and data structures to be compatible with both sunvnet and ldmvsw drivers. Details: Sunvnet operates on "vnet-port" nodes which appear in the Machine Description (MD) in a guest domain. Ldmvsw operates on "vsw-port" nodes which appear in the MD of a service domain. A difference between the sunvnet driver and the ldmvsw driver is the sunvnet driver creates a network interface (i.e. a struct net_device) for every vnet-port *parent* "network" node. Several vnet-ports may appear under this common parent network node - each corresponding to a common parent network interface. Conversely, since bridge/vswitch software will need to interface with every vsw-port in a system, the ldmvsw driver creates a network interface (i.e. a struct net_device) for every vsw-port - not every parent node as with sunvnet. This difference required some special handling in the common code as explained below. There are 2 key data structures used by the sunvnet and ldmvsw drivers (which are now found in sunvnet_common.h): 1. struct vnet_port This structure represents a vnet-port node in sunvnet and a vsw-port in the ldmvsw driver. 2. struct vnet This structure represents a parent "network" node in sunvnet and a parent "virtual-network-switch" node in ldmvsw. Since the sunvnet driver allocates a net_device for every parent "network" node, a net_device member appears in the struct vnet. Since the ldmvsw driver allocates a net_device for every port, a net_device member was added to the vnet_port. The common code distinguishes which structure net_device member to use by checking a 'vsw' bit that was added to the vnet_port structure. See the VNET_PORT_TO_NET_DEVICE() marco in sunvnet_common.h. The netdev_priv() in sunvnet is allocated as a vnet. The netdev_priv() in ldmvsw is a vnet_port. Therefore, any place in the common code where a netdev_priv() call was made, a wrapper function was implemented in each driver to first get the vnet and/or vnet_port (in a driver specific way) and pass them as newly added parameters to the common functions (see wrapper funcs: vnet_set_rx_mode() and vnet_poll_controller()). Since these wrapper functions call __tx_port_find(), __tx_port_find() was moved from the common code back into sunvnet.c. Note - ldmvsw.c does not require this function. These changes also required that port_is_up() be made into a common function and thus it was given a _common suffix and exported like the other common functions. A wrapper function was also added for vnet_start_xmit_common() to pass a driver-specific function arg to return the port associated with a given struct sk_buff and struct net_device. This was required because vnet_start_xmit_common() grabs a lock prior to getting the associated port. Using a function pointer arg allowed the code to work unchanged without risking changes to the non-trivial locking logic in vnet_start_xmit_common(). Signed-off-by: Aaron Young <aaron.young@oracle.com> Signed-off-by: Rashmi Narasimhan <rashmi.narasimhan@oracle.com> Reviewed-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Reviewed-by: Alexandre Chartre <Alexandre.Chartre@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
- Loading branch information
Aaron Young
authored and
David S. Miller
committed
Mar 18, 2016
1 parent
31762ea
commit 67d0719
Showing
3 changed files
with
121 additions
and
70 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.