On Mon, Apr 20, 2015 at 9:54 PM, Jesse Gross <je...@nicira.com> wrote: > On Mon, Apr 20, 2015 at 7:33 PM, Pravin Shelar <pshe...@nicira.com> wrote: >> On Mon, Apr 20, 2015 at 5:56 PM, Jesse Gross <je...@nicira.com> wrote: >>> On Mon, Apr 20, 2015 at 3:54 PM, Pravin Shelar <pshe...@nicira.com> wrote: >>>> On Mon, Apr 20, 2015 at 3:36 PM, Jesse Gross <je...@nicira.com> wrote: >>>>> On Mon, Apr 20, 2015 at 1:29 PM, Pravin B Shelar <pshe...@nicira.com> >>>>> wrote: >>>>>> diff --git a/datapath/linux/compat/stt.c b/datapath/linux/compat/stt.c >>>>>> new file mode 100644 >>>>>> index 0000000..209bf1a >>>>>> --- /dev/null >>>>>> +++ b/datapath/linux/compat/stt.c >>>>>> +static void update_headers(struct sk_buff *skb, bool head, >>>>>> + unsigned int l4_offset, unsigned int >>>>>> hdr_len, >>>>>> + bool ipv4, u32 tcp_seq) >>>>> [...] >>>>>> + skb->truesize = SKB_TRUESIZE(skb_end_offset(skb)) + >>>>>> skb->data_len; >>>>>> +} >>>>> >>>>> I wonder if there are any possible edge cases with resetting truesize >>>>> where the packet is still in someone's transmit queue (such as if we >>>>> are looping back packet). Do we need to orphan it first? >>>>> >>>> ok, I will orphan it in update_headers. >>> >>> Just to clarify - I was mostly just thinking aloud on orphaning it. >>> I'm not totally sure if that is the right thing to do or if this is >>> the right place to do it. I'm not sure what the conceptual >>> justification would be for it and it could potentially result in the >>> sender's buffers not being properly limited. Perhaps not resetting the >>> truesize is the right thing too... >>> >> I have seen warning msg if we do no keep truesize update along with >> changes to skb. > > Hmm, interesting, what is the warning? I don't think that I have seen > that before.
Actually skb_try_coalesce() is updating it correctly. so there no need to change truesize anymore. I will update patch accordingly. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
