On Tue, Jul 2, 2019 at 8:32 PM John Hurley <john.hur...@netronome.com> wrote: > > This patchset introduces a new TC action module that allows the > manipulation of the MPLS headers of packets. The code impliments > functionality including push, pop, and modify. > > Also included are tests for the new funtionality. Note that these will > require iproute2 changes to be submitted soon. > > NOTE: these patches are applied to net-next along with the patch: > [PATCH net 1/1] net: openvswitch: fix csum updates for MPLS actions > This patch has been accepted into net but, at time of posting, is not yet > in net-next. > > v4-v5: > - move mpls_hdr() call to after skb_ensure_writable - patch 3 > (Willem de Bruijn) > - move mpls_dec_ttl to helper - patch 4 (Willem de Bruijn) > - add iproute2 usage example to commit msg - patch 4 (David Ahern) > - align label validation with mpls core code - patch 4 (David Ahern) > - improve extack message for no proto in mpls pop - patch 4 (David Ahern) > v3-v4: > - refactor and reuse OvS code (Cong Wang) > - use csum API rather than skb_post*rscum to update skb->csum (Cong Wang) > - remove unnecessary warning (Cong Wang) > - add comments to uapi attributes (David Ahern) > - set strict type policy check for TCA_MPLS_UNSPEC (David Ahern) > - expand/improve extack messages (David Ahern) > - add option to manually set BOS > v2-v3: > - remove a few unnecessary line breaks (Jiri Pirko) > - retract hw offload patch from set (resubmit with driver changes) (Jiri) > v1->v2: > - ensure TCA_ID_MPLS does not conflict with TCA_ID_CTINFO (Davide Caratti) > > John Hurley (5): > net: core: move push MPLS functionality from OvS to core helper > net: core: move pop MPLS functionality from OvS to core helper > net: core: add MPLS update core helper and use in OvS > net: sched: add mpls manipulation actions to TC > selftests: tc-tests: actions: add MPLS tests
Reviewed-by: Willem de Bruijn <will...@google.com> I did have some conflicts applying the patches from patchwork (to diff v4 vs v5). Might be my process. This is clean against net-next, right?
