[ovs-dev] Inter-op openvswitch and openfcoe

[Anoob Soman]

Hi All,

I am aware there had been some discussion on running lldpad and 
open-fcoe utils (like fcoemon) on top of ovs, but couldn’t figure out a 
way to successfully run lldpad and fcoemon on top of openvswitch.

I did some experimentation with openvswitch and open-fcoe and now I am 
trying to get opinion from you guys about what would be the best 
approach to make fcoeuilts run on top of openvswitch. I used openvswitch 
v2.3.2 for my testing.
My experimentation was carried out using XenServer and in my 
experimentation I could see FIP and LLDP don’t reach lldpad and fcoemon 
daemons.

Bit of background what these daemon are. You can skip this paragraph, if 
you know about these daemons.
FCoE’s lossless ethernet can be achieved using dcb (dcbx protocol). dcb, 
in open-fcoe, is enabled using lldpad (LLDP agent daemon) which handles 
dbcx options and much more. dcb needs to be enabled and available on a 
interface for fcoemon to start fcoe operations.

I have figured out why lldpad and fcoemon don’t receive ETH_P_LLDP and 
ETH_P_FIP packets.
lldpad and fcoemon open ETH_P_LLDP and ETH_P_FIP raw sockets respectively.
Since the processing of raw socket packets (ptype_base) happens after 
openvswitch (rx_handler), when running in XenServer any raw socket 
listening on ethX interface, will not receive any packets, as 
openvswitch always return RX_HANDLER_CONSUMED. rx_handlers are only set 
for ethX and xenbrX (bridge interface) doesn’t have any rx_handler set. 
Ideally, if raw socket is listening on xenbrX interface it should 
receive the packets. But in case of lldpad it is not possible to make 
this daemon receive packet on xenbrX interface.

lldpad daemon opens PF_LLDP raw socket and it listens on all ports. If 
you consider XenServer, then it listens on xenbrX (bridge interface) and 
ethX interface. llpdad also queries for the dcb state, from the 
netdevice, using dcbnl_ops. As of now xenbrX (bridge interface) doesn’t 
have any dcbnl_ops, which mean lldpad will only be able to configure, 
listen, send, receive lldp pdu on ethX interfaces. Without dcb support 
on xenbrX interface, fcoemon will not start fcoe handling on xenbrX 
interface. This rules out having these daemons run on top of xenbrX 
(bridge interface).

So I am looking for an interface, similar to linux bridge, where setting 
an action of drop doesn’t drop the packet instead it returns 
RX_HANDLER_PASS and ptype_base handler (including packet_handler) can 
pickup the packet.

I did a proof of concept, by having a hack, in netdev_frame_hook() 
datapath/vport-netdev.c
if (skb->protocol == cpu_to_be16(ETH_P_FIP) ||  skb->protocol == 
cpu_to_be16(0x88CC))
return RX_HANDLER_PASS;
and this makes fcoemon and lldpad daemon work as expected.

If returning RX_HANDLER_PASS is the right approach to go forward, how do 
we design this into ovs. Can we have an action called “ignore" which 
will ignore certain flows from being processed by openvswitch. Is there 
any other approach that I can take.

Thanks,
Anoob.