On 12/10/2019 8:52 AM, Sathya Perla wrote: > On Sun, Dec 8, 2019 at 6:53 PM Eli Britstein <el...@mellanox.com> wrote: > ... >> +static int >> +parse_clone_actions(struct netdev *netdev, >> + struct flow_actions *actions, >> + const struct nlattr *clone_actions, >> + const size_t clone_actions_len, >> + struct offload_info *info) >> +{ >> + const struct nlattr *ca; >> + unsigned int cleft; >> + >> + NL_ATTR_FOR_EACH_UNSAFE (ca, cleft, clone_actions, clone_actions_len) { >> + int clone_type = nl_attr_type(ca); >> + >> + if (clone_type == OVS_ACTION_ATTR_TUNNEL_PUSH) { >> + const struct ovs_action_push_tnl *tnl_push = nl_attr_get(ca); >> + struct rte_flow_action_raw_encap *raw_encap = >> + xzalloc(sizeof *raw_encap); >> + >> + raw_encap->data = (uint8_t *)tnl_push->header; >> + raw_encap->preserve = NULL; >> + raw_encap->size = tnl_push->header_len; >> + >> + add_flow_action(actions, RTE_FLOW_ACTION_TYPE_RAW_ENCAP, >> + raw_encap); > Hi, converting OVS_TUNNLE_PUSH into RTE_RAW_ENCAP loses the 'tnl_type' > information provided by OVS. RAW_ENCAP provides the tunnel header just > as a blob of bits which may not be ideal for NIC HW to offload. > > How about using tnl_push->tnl_type field to parse the header and > compose specific tunnel encap actions like RTE_VXLAN_ENCAP, > RTE_NVGRE_ENCAP etc. > This would be also be more inline with how it's done with TC-offload.
I see your point. However, struct ovs_action_push_tnl has the "header" field just as a raw binary buffer, and not detailed like in TC. "tnl_type" has a comment /* For logging. */. It is indeed used for logging, as in lib/odp-util.c, in function format_odp_tnl_push_header. using VXLAN_ENCAP instead of RAW_ENCAP will make the push less generic, as I will have to parse the header to build the vxlan_encap fields, just so they can re-build as a raw header in the PMD level, so I don't see the offload benefit of it. Another point is that this way it will support any header, not just VXLAN (as an example). > > thanks! _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev