Re: [RFC PATCH net-next] netfilter: nf_conntrack: add ct expression support for netdev egress chains

[Florian Westphal <fw@strlen.de>]

Hari Chandrakanthan <hari.chandrakanthan@oss.qualcomm.com> wrote:
> I agree that enabling inet/bridge conntrack solely for netdev/egress 
> would be unnecessary overhead.

Not following.  What is 'netdev egress only'?
Where are the skbs coming from, i.e. though what pipeline?

Bridge?
Routing?

> To address this, as suggested by Pablo, we are considering enabling 
> conntrack lookup/creation at
> netdev/ingress. This would allow netdev chains to access conntrack state 
> without requiring conntrack
> to be enabled for the inet or bridge families, avoiding unnecessary 
> overhead for netdev-only use cases.

FWIW bridge conntrack is already problematic (see recent RFC patch
to refag in INPUT, conntrack is pretty much routing-only.

> Kindly share your thoughts on this approach.

I think you'd have to explain your use case.

I thought you only want

skb-> mark = ct->mark

from egress. That would imply something else already enabled conntrack
anyway, else you'd have no conntrack marks set that you could read.