From: Neil Horman
Date: Fri, 28 Jun 2019 10:52:06 -0400
> Given that the socket transmit path is an exclusive path (locked via the
> pg_vec_lock mutex), we do not have the ability to increment this counter
> on multiple cpus in parallel. This implementation also seems to have
> the potential to
Hi Neil,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Neil-Horman/af_packet-convert-pending-frame-counter-to-atomic_t/20190629-032437
config: x86_64-randconfig-x007-201925 (attached as .config)
com
On Fri, Jun 28, 2019 at 11:15:09AM -0400, Willem de Bruijn wrote:
> On Fri, Jun 28, 2019 at 10:53 AM Neil Horman wrote:
> >
> > The AF_PACKET protocol, when running as a memory mapped socket uses a
> > pending frame counter to track the number of skbs in flight during
> > transmission. It is incr
On Fri, Jun 28, 2019 at 10:53 AM Neil Horman wrote:
>
> The AF_PACKET protocol, when running as a memory mapped socket uses a
> pending frame counter to track the number of skbs in flight during
> transmission. It is incremented during the sendmsg call (via
> tpacket_snd), and decremented (possib
The AF_PACKET protocol, when running as a memory mapped socket uses a
pending frame counter to track the number of skbs in flight during
transmission. It is incremented during the sendmsg call (via
tpacket_snd), and decremented (possibly asynchronously) in the skb
desructor during skb_free.
The c
