On Fri, Jul 26, 2013 at 8:54 AM, Kyle Mestery (kmestery) <[email protected]> wrote: > I'm hoping to get this done today, but had a question (was on PTO yesterday): > > I see in Jesse's reply to Pravin's patch [1] a mention of putting the new code > into the main path, and the compatibility code should be for older kernels. > My question to Jesse is this: When you made this comment, did you mean > the entire rpl___skb_gso_segment() function should be in the straight-line > code, and the compat code should default that back to __skb_gso_segment()? > That's what I was thinking, but wanted to verify before proceeding down > that path.
Effectively yes - in places where we care about the contents of skb->cb we should save and restore its contents in the main code base. We should just do this in places where we actually care about skb->cb though, which is probably not the case in most places. Essentially, the non-compat code should be written as if it were running against the latest kernel. X-CudaMail-Whitelist-To: [email protected] _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
