On Thu, Nov 8, 2012 at 1:06 AM, JieYue Ma <xiaoma80....@gmail.com> wrote:
> Hi,
>
> I am reading ovs code, while in function ovs_flow_to_nlattrs, we have
>
> ...
> if (swkey->eth.tci || swkey->eth.type == htons(ETH_P_8021Q)) {
> if (nla_put_be16(skb, OVS_KEY_ATTR_ETHERTYPE, htons(ETH_P_8021Q))
> ||
> nla_put_be16(skb, OVS_KEY_ATTR_VLAN, swkey->eth.tci))
> goto nla_put_failure;
> encap = nla_nest_start(skb, OVS_KEY_ATTR_ENCAP);
> if (!swkey->eth.tci)
> goto unencap;
> } else {
> encap = NULL;
> }
> ...
>
> here's the line: if swkey->eth.tci || swkey->eth.type ==
> htons(ETH_P_8021Q), well, is it POSSIBLE swkey->eth.tci being zero
> while swkey->eth.type == htons(ETH_P_8021Q)? Why we need the latter
> condition judgement?
> On my stand, from ovs_flow_extract, swkey->eth.type, in most
> situations, is ETH_P_IP, ETH_P_IPV6, or ETH_P_ARP. It can be
> ETH_P_8021Q when in nested VLAN scenarios, but swkey->eth.tci also
> non-zero. So, maybe swkey->eth.type == htons(ETH_P_8021Q) is
> unnecesary, isn't it?
It can happen if the packet is truncated so the EtherType is 0x8100 but it
is not long enough to contain a vlan header.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
