[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170418190535.GG4730@C02RW35GFVH8.dhcp.broadcom.net>
Date: Tue, 18 Apr 2017 15:05:35 -0400
From: Andy Gospodarek <andy@...yhouse.net>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: David Miller <davem@...emloft.net>, michael.chan@...adcom.com,
netdev@...r.kernel.org, xdp-newbies@...r.kernel.org
Subject: Re: [PATCH v4 net-next RFC] net: Generic XDP
On Fri, Apr 14, 2017 at 05:59:51PM -0700, Alexei Starovoitov wrote:
> On Thu, Apr 13, 2017 at 04:23:15PM -0400, David Miller wrote:
> > +
> > + switch (act) {
> > + case XDP_TX:
> > + __skb_push(skb, skb->mac_len);
>
> s/skb->mac_len/mac_len/
>
I was away from my keyboard for a few days, but was able to get some
time to test this today.
When using this change above suggested by Alexei, XDP_DROP and XDP_TX
actions appear to work well with xdp1 and xdp2.
I'm seeing some rather odd behavior with xdp_tx_tunnel so it might be
good to hold off on committing this just yet.
At first glance, it looks like there is enough headroom for the new
frame, but the resulting packet data do not look right and I'm actually
seeing some data that may be left on the stack from a previous caller.
> > + HARD_TX_UNLOCK(dev, txq);
> > + if (free_skb) {
> > + trace_xdp_exception(dev, xdp_prog, XDP_TX);
> > + kfree_skb(skb);
>
> nice that you didn't forget to add trace_xdp_exception in this path :)
>
> Overall looks good to me and other than the minor nit in tx, i think it
> should work for programs already used with in-driver xdp.
> I'll test it next week unless people beat me to it.
>
Powered by blists - more mailing lists