[ovs-dev] [PATCH v6] datapath: Add Stateless TCP Tunneling protocol.

[Pravin Shelar]

On Fri, Apr 17, 2015 at 1:11 PM, Jesse Gross <jesse at nicira.com> wrote:
> On Fri, Apr 17, 2015 at 1:05 PM, Pravin Shelar <pshelar at nicira.com> wrote:
>> On Fri, Apr 17, 2015 at 12:34 PM, Jesse Gross <jesse at nicira.com> wrote:
>>> On Thu, Apr 16, 2015 at 7:17 PM, Pravin B Shelar <pshelar at nicira.com> wrote:
>>>> +static struct sk_buff *push_stt_header(struct sk_buff *head, __be64 tun_id,
>>>> +                                      __be16 s_port, __be16 d_port,
>>>> +                                      __be32 saddr, __be32 dst,
>>>> +                                      __be16 l3_proto, u8 l4_proto,
>>>> +                                      int dst_mtu)
>>>> +{
>>>> +       struct sk_buff *skb;
>>>> +
>>>> +       if (skb_shinfo(head)->frag_list) {
>>>> +               bool ipv4 = (l3_proto == htons(ETH_P_IP));
>>>> +               bool tcp = (l4_proto == IPPROTO_TCP);
>>>> +               int l4_offset = skb_transport_offset(head);
>>>> +
>>>> +               if (unlikely(segment_skb(&head, ipv4, tcp, l4_offset)))
>>>> +                       goto error;
>>>> +       }
>>>
>>> I don't know that it's necessarily guaranteed that we have all of this
>>> information in the transmit path, especially given that we pass in
>>> checksum partial as true later on. In the event that we have just a
>>> bare Ethernet packet, we might not know the transport offset or that
>>> the TCP header is fully formed.
>>>
>> Bare Ethernet packet will get caught in can_segment() and will be linearized.
>> I am setting checksum partial true since stt push header will set it
>> later on anyways.
>
> What happens if we have an IP packet that indicates that the next
> protocol is TCP but is then truncated? I don't think that
> can_segment() will do anything about that.
>
If the packet is truncated it will be detected before we start segmenting it.
skb_list_segment() does pull in tcp header. I am not sure how does it matter.

> These functions are segmenting the inner packet before the STT header
> is pushed on, so the later setting doesn't really matter. (By the way,
> the check for checksum partial is not really about the checksum status
> - it's whether we have information about the offsets, primarily on the
> receive side.)

That is the reason I wanted to keep checksum partial true for transmit
side. Because we will always have checksum offsets on transmit side.
Offset may be incorrect at the time of segmentation but we will fix it
once STT header is pushed.