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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
