"Kavanagh, Mark B" <[email protected]> writes: >>Hi Mark, >> >>Mark Kavanagh <[email protected]> writes: >> >>> TCP Segmentation Offload (TSO) is a feature which enables >>> the TCP/IP network stack to delegate segmentation of a TCP >>> segment to the NIC, thus saving compute resources. >>> >>> This commit adds support for TSO in the DPDK vHost-User backend, >>> to OvS v2.6.1; this enables a guest to offload segmentation of >>> TCP segments that it sends to OvS. >>> >>> This patch is not intended for upstreaming, but rather was produced >>> in response to requests for an updated version of the initial TSO RFC >>> patch posted here: >>> https://mail.openvswitch.org/pipermail/ovs-dev/2016-June/316414.html >>> >>> Signed-off-by: Mark Kavanagh <[email protected]> >>> --- >> >>... >> >>> diff --git a/lib/packets.c b/lib/packets.c >>> index e4c29d5..2417ba2 100644 >>> --- a/lib/packets.c >>> +++ b/lib/packets.c >>> @@ -33,6 +33,10 @@ >>> #include "dp-packet.h" >>> #include "unaligned.h" >>> >>> +#ifdef DPDK_NETDEV >>> +#include "rte_ether.h" >>> +#endif >>> + >>> const struct in6_addr in6addr_exact = IN6ADDR_EXACT_INIT; >>> const struct in6_addr in6addr_all_hosts = IN6ADDR_ALL_HOSTS_INIT; >>> >>> @@ -204,6 +208,11 @@ eth_push_vlan(struct dp_packet *packet, ovs_be16 tpid, >>> ovs_be16 tci) >>> memmove(veh, (char *)veh + VLAN_HEADER_LEN, 2 * ETH_ADDR_LEN); >>> veh->veth_type = tpid; >>> veh->veth_tci = tci & htons(~VLAN_CFI); >>> + >>> +#ifdef DPDK_NETDEV >>> + struct rte_mbuf *pkt = &(packet->mbuf); >>> + pkt->l2_len += sizeof(struct vlan_hdr); >>> +#endif >>> } >>> >>> /* Removes outermost VLAN header (if any is present) from 'packet'. >>> @@ -221,6 +230,11 @@ eth_pop_vlan(struct dp_packet *packet) >>> memmove((char *)veh + VLAN_HEADER_LEN, veh, 2 * ETH_ADDR_LEN); >>> dp_packet_resize_l2(packet, -VLAN_HEADER_LEN); >>> } >>> + >>> +#ifdef DPDK_NETDEV >>> + struct rte_mbuf *pkt = &(packet->mbuf); >>> + pkt->l2_len -= sizeof(struct vlan_hdr); >>> +#endif >>> } >>> >>> /* Set ethertype of the packet. */ >> >>Would it be better to change the dp_packet_resize_l2 call? Are you > > Hey Aaron, > > Good call - that would definitely be a more suitable location. > >>worried about the mpls case? > > I haven't considered mpls here at all, as it wasn't part of the use > case for which this new version of the patch was produced I'm afraid. > Out of curiosity, what is your concern here?
The two users of dp_packet_resize_l2 are the vlan and the mpls code. I had assumed you skipped for that reason, but maybe that isn't the case. > Thanks in advance, > Mark _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
