>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?

Thanks in advance,
Mark
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to