Jesse Gross wrote (on Fri 03 Jan, 2014 at 23:48 GMT):
On Thu, Jan 2, 2014 at 8:33 PM, Chris Luke <chr...@flirble.org> wrote:
Jesse Gross wrote (on Fri 03 Jan, 2014 at 00:27 GMT):
On Thu, Jan 2, 2014 at 6:01 PM, Chris Luke <chr...@flirble.org> wrote:
On Jan 2, 2014, at 16:51, Jesse Gross <je...@nicira.com> wrote:
On Mon, Dec 23, 2013 at 11:46 PM, Chris Luke <chr...@flirble.org>
wrote:
Jesse Gross wrote (on Tue 24 Dec, 2013 at 03:05 GMT):
* This type of concept has come up before and its usually in the
context of allowing an existing daemon like lldpad to be run on an OVS
port. At a minimum, we would need to make sure that whatever we do
here is compatible with that and ideally we would be able to
essentially solve both problems at the same time. If you are planning
on running routing protocol daemons then maybe it is already pretty
similar.
Exactly. I have lldpd running on my test setup and it appears to work
fine, but I'll dig into it to be sure.
Do the packets sent from the daemon go through OVS? It doesn't seem
like they would and while this would likely work in many cases, it is
odd.
No, from the daemon they go directly out the port. The case that needs
OVS involvement is incoming packets.
I believe that it works correctly in most cases but it seems somewhat
weird and asymmetric. Is there anything that we can do about it?
I think it's just the nature of it - the datapath only hooks into the
receive path of ports. If you wanted DP involvement in the other direction
we'd need some hook into host-originated traffic. That would certainly
make it feel more symmetric from a user perspective. I can take that on if
it's interesting for OVS.
I think it's worth looking into at least. It seems like it's probably
nicer to the user and it might even just fit in logically with
whatever other changes we need to have a nice hook.
The only hook I have found so far for originated traffic uses the AF_PACKET
interface - but that has *all* outgoing traffic for a given port, no
easy indication of local origination and no method to drop or modify the
skb.
Moreover, since the LLDP daemons all craft their own raw packets and
inject them, using AF_PACKET, into the output queues of target interfaces,
there's no easy way to identify them either.
The simplest mechanism I can think of to work with both issues is to add a
flag to the skb that says OVS touched the skb.
We would have two places this is used:
1) In __netif_receive_skb_core() it would effectively skip eveythhing until
just after the rx_handler section. There is in fact only a simple loop that
we need, that iterates ptype_base[protocol] and delivers a clone of the skb
to each handler registered there (an alternative mechanic being that we
split that loop into its own helper function and use it directly). ptype_base
is where, eg, ipv4, ipv6, arp etc register their hooks.
2) We'd have to introduce a tx handler mechanism similar to rx_handler that
allows us to signal back to the kernel whether we took the packet or are
handing it back. We'd use the new flag in the skb to understand we already
made a decision on the flow and can pass it on. This hook would be in
dev_hard_start_xmit(), which calls a helper dev_queue_xmit_nit() to do the
AF_PACKET hooking already. The subtle part here is that we are left with
only traffic that was locally originated, however it was originated, and
traffic the kernel has forwarded to the output port from a non OVS-hooked
port. Both cases are ones that we might want OVS control over.
(In the kernel routed cases, if it came in on an OVS port and was handed
back_to_kernel then it gets the flag, the combination of which implies
"the kernel now has authority over this skb' and we woulkd ignore it on
egress.)
There is precedent for random kernel modules having data in the skb, judging
by the hodge podge of stuff in there!
Merging the other email....
I think I would be inclined to argue that lldpd is doing it the
wrong way, that ETH_P_ALL packet sockets are meant as monitoring
taps, not protocol handlers.
Hmm, that is interesting that there is a difference.
net/core/dev.c, __netif_receive_skb_core(). Theres an iterator
for ptype_all before the rx_handler hook and one for ptype_base[prot]
right after it. These are similar, but not the same. In particular,
in the af_packet protocol code, if you use the ETH_P_ALL protocol
when you open the socket, or bind it, then it hooks into ptype_all
instead of ptype_base. For most applications it makes no difference.
It's only because rx_handler is inbetween these two that we notice.
I would be
inclined to agree (and I think open-lldp, which I believe is the same
as lldpad, is the more popular one). The other daemon that I've heard
brought up for this use case is Open FCoE so it would be interesting
to check what that uses as well.
I've found a third LLDP daemon, called OpenLLDP (no hyphen). The code is
much cruder and uses a protocol-specific hook. I'll play with the FCoE
guy when I get a moment.
However, I've crafted a dumb AF_PACKET dumper so I can observe what it
really sees and I can confirm my PACKET_LOOPBACK trick is not doing
exactly what I thought it was. I'll carry on looking for a reliable
workaround but yes, for consistency and simple cleanliness, we'll need a
kernel tweak to do this properly. (though what I have works for my more
simple use case, so at least I can progress my day job!)
Cheers,
Chris.
--
== chr...@flirble.org
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
