ixgbe rx & tx locks

[Jack Vogel]

Ah yes, at one time I was keeping the RX side lock when calling the stack,
but then as I recall that had problems, so the code now releases and
reaquires
as you can see. It results in some contention but I'm not sure that's
avoidable.

I've seen some LRO related panics on the 1G driver that may be related to
this lock release, or that's one theory I have..

Thanks for the testing Vijay!

Jack


On Tue, Sep 25, 2012 at 1:19 PM, Vijay Singh <vijju.singh at gmail.com> wrote:

> > Vijay, can you test this to see if it helps with your test case?
> >
> >> Jack
>
> John, apologies for the delay. I have some data to share now.
>
> With your patch, the transmit side lock contention is all gone.
> However I still see receive side contention. I have MSI/X enabled,
> with one hw queue per-port.
>
> debug.lock.prof.stats:
> lock                                              held_at
>              contested_from           instances
> e1b:rx(0)                       (    sys/dev/ixgbe/ixgbe.c:4314)        (
> sys/dev/ixgbe/ixgbe.c:4249)       6814
> e2b:rx(0)                       (    sys/dev/ixgbe/ixgbe.c:4314)        (
> sys/dev/ixgbe/ixgbe.c:4249)       6962
>
> These are from:
>
> 4297 static bool
> 4298 ixgbe_rxeof(struct ix_queue *que, int count)
> 4299 {
> .....
> 4314         IXGBE_RX_LOCK(rxr);
>
> and
>
> 4220 static __inline void
> 4221 ixgbe_rx_input(struct rx_ring *rxr, struct ifnet *ifp, struct
> mbuf *m, u32 ptype)
> 4222 {
> ....
> 4247         IXGBE_RX_UNLOCK(rxr);
> 4248         (*ifp->if_input)(ifp, m);
> 4249         IXGBE_RX_LOCK(rxr);
>
> So it seems like the interrupt handler is still contending with a
> taskqueue handler on the receive side.
>
> -vijay
>
> PS: The interface names are custom.
>