any reason to put output-mark on its own line? Why not
        mark 0x10000/0x3ffff output-mark 0x20000

Hi David

I will move it to the same line in v3.

is the documentation clear on the difference between mark and output-mark?

Lorenzo has described the differences in detail in the kernel commit I
had listed in the commit text of this patch. Pasting from there -

The output mark differs from the existing xfrm mark in two ways:

1. The xfrm mark is used to match xfrm policies and states, while
   the xfrm output mark is used to set the mark (and influence
   the routing) of the packets emitted by those states.
2. The existing mark is constrained to be a subset of the bits of
   the originating socket or transformed packet, but the output
   mark is arbitrary and depends only on the state.

The use of a separate mark provides additional flexibility. For

- A packet subject to two transforms (e.g., transport mode inside
  tunnel mode) can have two different output marks applied to it,
  one for the transport mode SA and one for the tunnel mode SA.
- On a system where socket marks determine routing, the packets
  emitted by an IPsec tunnel can be routed based on a mark that
  is determined by the tunnel, not by the marks of the
  unencrypted packets.
- Support for setting the output marks can be introduced without
  breaking any existing setups that employ both mark-based
  routing and xfrm tunnel mode. Simply changing the code to use
  the xfrm mark for routing output packets could xfrm mark could
  change behaviour in a way that breaks these setups.

@@ -61,6 +61,7 @@ static void usage(void)
fprintf(stderr, " [ flag FLAG-LIST ] [ sel SELECTOR ] [ LIMIT-LIST ] [ encap ENCAP ]\n"); fprintf(stderr, " [ coa ADDR[/PLEN] ] [ ctx CTX ] [ extra-flag EXTRA-FLAG-LIST ]\n");
        fprintf(stderr, "        [ offload [dev DEV] dir DIR ]\n");
+       fprintf(stderr, "        [ output-mark OUTPUT-MARK]\n");

Nit: I think you want a space between OUTPUT-MARK and ].


I will update this as well.

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Reply via email to