[Bug 227100] [epair] epair interface stops working when it reaches the hardware queue limit

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Fri Mar 30 04:21:58 UTC 2018


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227100

            Bug ID: 227100
           Summary: [epair] epair interface stops working when it reaches
                    the hardware queue limit
           Product: Base System
           Version: CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: reshadpatuck1 at gmail.com

Created attachment 191964
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=191964&action=edit
the output of netstat and dtrace

When the epair interface reaches the hardware queue limit, epairs stop
transferring data.

This bug refers to this mailing list conversation
https://lists.freebsd.org/pipermail/freebsd-net/2018-March/050077.html

So far using the patch/if_epair source file attached to this bug we can tell
that the error occurs in this block of code

```
        if ((epair_dpcpu->epair_drv_flags & IFF_DRV_OACTIVE) != 0) {
                /*
                 * Our hardware queue is full, try to fall back
                 * queuing to the ifq but do not call ifp->if_start.
                 * Either we are lucky or the packet is gone.
                 */
                IFQ_ENQUEUE(&ifp->if_snd, m, error);
                if (!error)
                        (void)epair_add_ifp_for_draining(ifp);

                SDT_PROBE3(if_epair, transmit, epair_transmit_locked, enqueued,
                                ifp, m, error);
                return (error);
        }
```

Where the value of the 'error' is 55.

Setting 'net.link.epair.netisr_maxqlen' to a very small value makes this occur
faster.

This issue seems to be happening in the wild only on one of my servers.
Other servers under more load in different environments do not seem to exhibit
this behaviour.

@Kristof please chime in if I have missed something out.

Attached:
- commands.txt
- epair-sdt-diff.patch 
- epair_transmit_locked:enqueued-error-code.d
- if_epair.c

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list