On Tue, Nov 13, 2012 at 01:33:35PM -0800, Jesse Gross wrote: > On Tue, Nov 13, 2012 at 10:42 AM, Ansis Atteka <aatt...@nicira.com> wrote: > > > On Tue, Nov 13, 2012 at 8:05 PM, Ben Pfaff <b...@nicira.com> wrote: > > > On Tue, Nov 13, 2012 at 07:52:47PM +0200, Ansis Atteka wrote: > > >> This patch adds support for skb mark matching and set action. > > >> > > >> Signed-off-by: Ansis Atteka <aatt...@nicira.com> > > > > > > Are there any common use cases for skb marking in which the mark might > > > vary on a per-packet basis? If so, then having the mark in the match > > > would have a lot of bad effects, such as proliferation of kernel flows > > > and possible packet reordering. > > > > Marks are handy for IPSEC tunnels. For example, one can use iptables > > rules to set mark on IPSEC packets and once that packet is > > decapulated, then it would retain the same skb mark. In this scenario > > marks would not change on a per-packet basis. > > > > I think that Jesse also had some other use-cases in mind. I would have > > to talk with him to get more details. > > > The immediate desire is for the IPsec tunnel use case that Ansis mentioned. > More generally, I could see it be used to provide better interaction with > iptables and other components that support marks. > > It's certainly possible to create situations where the skb mark would > significantly expand the number of flows that we see (maybe different marks > for each TCP flag, for example). However, the common way to use these > marks is for flow based features (i.e. to influence QoS or routing) so I > think it's unlikely to cause problems for us.
OK, thanks. I knew about the immediate purpose, of course, but I wanted to make sure that there wasn't a pitfall. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
