On Thu, 12 Nov 2020 00:43:01 +0100 Pablo Neira Ayuso wrote:
> no objections from my side to this patch, thanks.
Applied, thanks!
Hi Martin,
On Tue, Nov 10, 2020 at 04:02:13PM +0100, Martin Willi wrote:
> Hi Pablo,
>
> > > +static int vrf_output6_direct_finish(struct net *net, struct sock *sk,
> > > + struct sk_buff *skb)
> > > +{
> > > + vrf_finish_direct(skb);
> > > +
> > > + return vrf_ip6_l
Hi Pablo,
> > +static int vrf_output6_direct_finish(struct net *net, struct sock *sk,
> > +struct sk_buff *skb)
> > +{
> > + vrf_finish_direct(skb);
> > +
> > + return vrf_ip6_local_out(net, sk, skb);
> > +}
> > +
> > static int vrf_output6_direct(struct net *
Hi Martin,
Just a few nitpicks, see below.
On Fri, Nov 06, 2020 at 08:30:30AM +0100, Martin Willi wrote:
> VRF devices use an optimized direct path on output if a default qdisc
> is involved, calling Netfilter hooks directly. This path, however, does
> not consider Netfilter rules completing asyn
On 11/9/20 4:44 PM, Jakub Kicinski wrote:
> On Fri, 6 Nov 2020 08:30:30 +0100 Martin Willi wrote:
>> VRF devices use an optimized direct path on output if a default qdisc
>> is involved, calling Netfilter hooks directly. This path, however, does
>> not consider Netfilter rules completing asynchron
On Fri, 6 Nov 2020 08:30:30 +0100 Martin Willi wrote:
> VRF devices use an optimized direct path on output if a default qdisc
> is involved, calling Netfilter hooks directly. This path, however, does
> not consider Netfilter rules completing asynchronously, such as with
> NFQUEUE. The Netfilter ok
VRF devices use an optimized direct path on output if a default qdisc
is involved, calling Netfilter hooks directly. This path, however, does
not consider Netfilter rules completing asynchronously, such as with
NFQUEUE. The Netfilter okfn() is called for asynchronously accepted
packets, but the VRF
