[Bug 239118] in ESXi: Panic in ether_output_frame

[bugzilla-noreply at freebsd.org]

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

--- Comment #9 from Patrick Kelsey <pkelsey at freebsd.org> ---
(In reply to Marius Strobl from comment #7)
> I'd say that with an INTx-type interrupt or a single MSI vector, i. e. all
> the "legacy" interrupt support iflib is about, there's just no other way
> than to operate in combined RXTX mode (as opposed to multiple MSI-X vectors
> which can be associated to either RX or TX on a per-vector basis).
> Thus, - as actually already written in my private e-mail to pkelsey@ and the
> submitter on June 25th - I fully agree with markj@ analysis that
> vmxnet3_isc_txd_credits_update() currently isn't reentrant as well as with
> his fix (I'd probably code it to be more in line with the index updating in
> vmxnet3_isc_rxd_available(), though).
> However, as I also already wrote in said e-mail, on top of that it isn't
> obvious to me that it's safe to update txc->vxcr_next and txc->vxcr_gen
> non-atomically/lockless since r343291 dropped the locking around these
> operations.

Marius, you are missing the point, which is that you have failed to consider
the case of drivers that don't use TX interrupts at all, of which the vmx
driver is an example.  Drivers that don't use TX interrupts still only have one
queue-related interrupt in legacy mode.

By assuming that all drivers want to (i.e., are designed to) do TX processing
during their RX interrupts, even when those drivers have clearly indicated they
are not implementing TX mode or RXTX mode hardware interrupts in their
interface to iflib, you are breaking drivers such as vmx.

I fully agree that vmxnet3_isc_txd_credits_update() is not re-entrant - because
it was explicitly designed on the basis that it does not have to be.  Anyone of
course is welcome to redesign the vmx driver under changed design assumptions,
and I would caution anyone going down that path that the whole vmx driver
should be re-examined in this case.

I think it would be better to fix the iflib legacy mode interrupt setup so it
does not assume it can invoke TX processing from the RX interrupt unless the
driver has indicated it is using TXRX mode, or perhaps indicated that it is
using hardware-based TX interrupts.

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