> > I thought we have established that checking device MTU (m*T*u)
> > at ingress makes a very limited amount of sense, no?
> >
> > Shooting from the hip here, but won't something like:
> >
> > if (!skb->dev || skb->tc_at_ingress)
> > return SKB_MAX_ALLOC;
> > return skb->dev->mtu +
> I thought we have established that checking device MTU (m*T*u)
> at ingress makes a very limited amount of sense, no?
>
> Shooting from the hip here, but won't something like:
>
> if (!skb->dev || skb->tc_at_ingress)
> return SKB_MAX_ALLOC;
> return skb->dev->mtu + skb->dev->hard_
On Wed, 6 May 2020 16:32:59 -0700 Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> __bpf_skb_max_len(skb) is used from:
> bpf_skb_adjust_room
> __bpf_skb_change_tail
> __bpf_skb_change_head
>
> but in the case of forwarding we're likely calling these functions
> during receive p
From: Maciej Żenczykowski
__bpf_skb_max_len(skb) is used from:
bpf_skb_adjust_room
__bpf_skb_change_tail
__bpf_skb_change_head
but in the case of forwarding we're likely calling these functions
during receive processing on ingress and bpf_redirect()'ing at
a later point in time to egress o
4 matches
Mail list logo