> On Tue, 19 May 2020 15:31:20 +0200
> Daniel Borkmann wrote:
>
> > On 5/19/20 2:02 AM, David Ahern wrote:
> > > On 5/18/20 3:06 PM, Daniel Borkmann wrote:
> > >>
> > >> So given we neither call this hook on the skb path, nor XDP_TX nor
> > >> AF_XDP's TX path, I was wondering also wrt the disc
On 5/19/20 7:31 AM, Daniel Borkmann wrote:
> I meant that the dev{map,hash} would get extended in a way where the
> __dev_map_update_elem() receives an (ifindex, BPF prog fd) tuple from
> user space and holds the program's ref as long as it is in the map slot.
> Then, upon redirect to the given dev
Daniel Borkmann writes:
> On 5/19/20 2:02 AM, David Ahern wrote:
>> On 5/18/20 3:06 PM, Daniel Borkmann wrote:
>>> So given we neither call this hook on the skb path, nor XDP_TX nor
>>> AF_XDP's TX
>>> path, I was wondering also wrt the discussion with John if it makes
>>> sense to
>>> make this
On Tue, 19 May 2020 15:31:20 +0200
Daniel Borkmann wrote:
> On 5/19/20 2:02 AM, David Ahern wrote:
> > On 5/18/20 3:06 PM, Daniel Borkmann wrote:
> >>
> >> So given we neither call this hook on the skb path, nor XDP_TX nor
> >> AF_XDP's TX path, I was wondering also wrt the discussion with
> >>
On 5/19/20 2:02 AM, David Ahern wrote:
On 5/18/20 3:06 PM, Daniel Borkmann wrote:
So given we neither call this hook on the skb path, nor XDP_TX nor
AF_XDP's TX
path, I was wondering also wrt the discussion with John if it makes
sense to
make this hook a property of the devmap _itself_, for exam
David Ahern wrote:
> On 5/18/20 12:10 PM, John Fastabend wrote:
> >>
> >> host ingress to VM is one use case; VM to VM on the same host is another.
> >
> > But host ingress to VM would still work with tail calls because the XDP
> > packet came from another XDP program. At least that is how I under
On 5/18/20 3:06 PM, Daniel Borkmann wrote:
> So given we neither call this hook on the skb path, nor XDP_TX nor
> AF_XDP's TX
> path, I was wondering also wrt the discussion with John if it makes
> sense to
> make this hook a property of the devmap _itself_, for example, to have a
> default
> BPF p
On 5/18/20 12:10 PM, John Fastabend wrote:
>>
>> host ingress to VM is one use case; VM to VM on the same host is another.
>
> But host ingress to VM would still work with tail calls because the XDP
> packet came from another XDP program. At least that is how I understand
> it.
>
> VM to VM case,
On 5/18/20 12:00 PM, Toke Høiland-Jørgensen wrote:
> I meant 'less powerful' in the obvious sense: it only sees a subset of
> the packets going out of the interface. And so I worry that it will (a)
> make an already hard to use set of APIs even more confusing, and (b)
> turn out to not be enough so
On 5/18/20 4:44 PM, David Ahern wrote:
On 5/18/20 3:08 AM, Toke Høiland-Jørgensen wrote:
I can see your point that fixing up the whole skb after the program has
run is not a good idea. But to me that just indicates that the hook is
in the wrong place: that it really should be in the driver, exec
On 5/18/20 8:00 PM, Toke Høiland-Jørgensen wrote:
David Ahern writes:
On 5/18/20 3:08 AM, Toke Høiland-Jørgensen wrote:
[...]
Less powerful how? There are only so many operations you can do to a
packet. What do you want to do and what can't be done with this proposed
change? Why must it be do
David Ahern wrote:
> On 5/15/20 4:54 PM, John Fastabend wrote:
> > Hi David,
> >
> > Another way to set up egress programs that I had been thinking about is to
> > build a prog_array map with a slot per interface then after doing the
> > redirect (or I guess the tail call program can do the redire
David Ahern writes:
> On 5/18/20 3:08 AM, Toke Høiland-Jørgensen wrote:
>> I can see your point that fixing up the whole skb after the program has
>> run is not a good idea. But to me that just indicates that the hook is
>> in the wrong place: that it really should be in the driver, executed at
>
On 5/18/20 3:08 AM, Toke Høiland-Jørgensen wrote:
> I can see your point that fixing up the whole skb after the program has
> run is not a good idea. But to me that just indicates that the hook is
> in the wrong place: that it really should be in the driver, executed at
> a point where the skb data
David Ahern writes:
> On 5/13/20 4:43 AM, Toke Høiland-Jørgensen wrote:
>> I don't like this. I makes the egress hook asymmetrical with the ingress
>> hook (ingress hook sees all traffic, egress only some of it). If the
>> performance hit of disabling GSO is the concern, maybe it's better to
>> w
I am trying to understand the resistance here. There are ingress/egress
hooks for most of the layers - tc, netfilter, and even within bpf APIs.
Clearly there is a need for this kind of symmetry across the APIs, so
why the resistance or hesitation for XDP?
Stacking programs on the Rx side into the
On 5/15/20 4:54 PM, John Fastabend wrote:
> Hi David,
>
> Another way to set up egress programs that I had been thinking about is to
> build a prog_array map with a slot per interface then after doing the
> redirect (or I guess the tail call program can do the redirect) do the
> tail call into the
David Ahern wrote:
> On 5/13/20 4:43 AM, Toke Høiland-Jørgensen wrote:
> > I don't like this. I makes the egress hook asymmetrical with the ingress
> > hook (ingress hook sees all traffic, egress only some of it). If the
> > performance hit of disabling GSO is the concern, maybe it's better to
> >
On 5/13/20 4:43 AM, Toke Høiland-Jørgensen wrote:
> I don't like this. I makes the egress hook asymmetrical with the ingress
> hook (ingress hook sees all traffic, egress only some of it). If the
> performance hit of disabling GSO is the concern, maybe it's better to
> wait until we figure out how
David Ahern writes:
> From: David Ahern
>
> This series adds support for XDP in the egress path by introducing
> a new XDP attachment type, BPF_XDP_EGRESS, and adding a UAPI to
> if_link.h for attaching the program to a netdevice and reporting
> the program. This allows bpf programs to be run on
From: David Ahern
This series adds support for XDP in the egress path by introducing
a new XDP attachment type, BPF_XDP_EGRESS, and adding a UAPI to
if_link.h for attaching the program to a netdevice and reporting
the program. This allows bpf programs to be run on redirected xdp
frames with the c
21 matches
Mail list logo
