On Mon, Jul 27, 2015 at 9:59 AM, Anoob Soman <anoob.so...@citrix.com> wrote: > 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.
I think there's roughly three possible approaches: #1: Replicate support for these protocols in OVS, which would be able to install the appropriate flows directly in the datapath to get these packets itself. #2: Add some mechanism where these daemons can talk to OVS and have them cooperate to get the appropriate packets, while still keeping the logic in the original daemon. #3: The method that you are describing, where OVS has a mechanism to allow the existing daemons to work unmodified. There is already a little LLDP code in OVS to support certain functionality (auto-attach), so I guess that means that we have roughly started down path #1. However, in that case, I think that was new functionality that did not also exist in lldpad. I think the main issue with #3 is finding a way to make things work together cleanly. If OVS is managing the switch configuration, how does it interact with these external daemons? What happens if they are used together with the OVS LLDP code? Can this be handled automatically without making the user understand the details of the kernel implementation? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
