Page MenuHomeFreeBSD

Workaround the rare condition in VNIC when the empty fragment is received
AbandonedPublic

Authored by zbb on Nov 20 2015, 6:48 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Mar 24, 6:11 PM
Unknown Object (File)
Feb 23 2024, 3:10 PM
Unknown Object (File)
Nov 22 2023, 8:22 AM
Unknown Object (File)
Nov 13 2023, 1:28 PM
Unknown Object (File)
Nov 3 2023, 11:34 PM
Unknown Object (File)
Oct 25 2023, 9:00 AM
Unknown Object (File)
Sep 20 2023, 11:23 AM
Unknown Object (File)
Sep 11 2023, 5:30 PM
Subscribers

Details

Summary

Even though HW informs that there are multiple packet fragments received,
the secondary fragment (provided by the descriptor filled-out by HW) may
be empty. This situation will cause driver to call panic. To temporarily
workaround this problem just drop packets that were received in multiple
fragments of which one is empty.

Pointed out by: emaste
Reviewed by:
Obtained from: Semihalf
Differential Revision:

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

zbb retitled this revision from to Workaround the rare condition in VNIC when the empty fragment is received.
zbb updated this object.
zbb edited the test plan for this revision. (Show Details)
zbb added reviewers: emaste, imp, ian.
zbb set the repository for this revision to rS FreeBSD src repository - subversion.
zbb added a reviewer: wma_semihalf.com.
zbb added a subscriber: arm64.
sys/dev/vnic/nicvf_queues.c
304–324

Can we extend the comment to provide more background here? Does the hardware report that a packet is available before the 2nd slot is filled in or something like that?

Overall I think this is a reasonable workaround to allow us to make progress, but the comment should explain more about how this might happen.

zbb edited edge metadata.
zbb removed rS FreeBSD src repository - subversion as the repository for this revision.

I suggest we add statistics/counters for that particular situation. It'd be good to track it down and check if all hw is prone to this issue or it's only one which Ed was using.

I suggest we add statistics/counters for that particular situation. It'd be good to track it down and check if all hw is prone to this issue or it's only one which Ed was using.

Seems like a good idea -- maybe it's not an issue with 2.0 silicon?

zbb planned changes to this revision.Feb 26 2016, 3:21 PM

Wrong solution.