queue 7 is not default, it is caused by the filter tables.
The fields are including queue number, not bitfields.
So MVXPE_DF_QUEUE_ALL (b111) means queue 7.
And also, pass all unicast addresses if it is promisc mode.
MVXPE_PXC_UPM is working in almost cases,
but this change is needed for some cases; bridging frames through inter units,
using products have consecutive MAC addresses.
This change intends to run the whole network stack in softint context
(or normal LWP), not hardware interrupt context. Note that the work is
still incomplete by this change; to that end, we also have to softint-ify
if_link_state_change (and bpf) which can still run in hardware interrupt.
This change softint-ifies at ifp->if_input that is called from
each device driver (and ieee80211_input) to ensure Layer 2 runs
in softint (e.g., ether_input and bridge_input). To this end,
we provide a framework (called percpuq) that utlizes softint(9)
and percpu ifqueues. With this patch, rxintr of most drivers just
queues received packets and schedules a softint, and the softint
dequeues packets and does rest packet processing.
To minimize changes to each driver, percpuq is allocated in struct
ifnet for now and that is initialized by default (in if_attach).
We probably have to move percpuq to softc of each driver, but it's
future work. At this point, only wm(4) has percpuq in its softc
as a reference implementation.
Additional information including performance numbers can be found
in the thread at tech-kern@ and tech-net@:
http://mail-index.netbsd.org/tech-kern/2016/01/14/msg019997.html
Acknowledgment: riastradh@ greatly helped this work.
Thank you very much!
- Add PCI Extended Configuration Space support into x86.
- Check register offset of pci_conf_read() in MD part. It returns (pcireg_t)-1
if it isn't accessible.
- Decode Extended Capability in PCI Extended Configuration Space.
Currently the following extended capabilities are decoded:
- Advanced Error Reporting
- Virtual Channel
- Device Serial Number
- Power Budgeting
- Root Complex Link Declaration
- Root Complex Event Collector Association
- Access Control Services
- Alternative Routing-ID Interpretation
- Address Translation Services
- Single Root IO Virtualization
- Page Request
- TPH Requester
- Latency Tolerance Reporting
- Secondary PCI Express
- Process Address Space ID
- LN Requester
- L1 PM Substates
The following extended capabilities are not decoded yet:
- Root Complex Internal Link Control
- Multi-Function Virtual Channel
- RCRB Header
- Vendor Unique
- Configuration Access Correction
- Multiple Root IO Virtualization
- Multicast
- Resizable BAR
- Dynamic Power Allocation
- Protocol Multiplexing
- Downstream Port Containment
- Precision Time Management
- M-PCIe
- Function Reading Status Queueing
- Readiness Time Reporting
- Designated Vendor-Specific
this driver controls CESA unit as same as mvcesa, but uses DMA engines and
does CBC operations, HMAC operations by hardware. about 2 kbytes of data
are processed at one. supported algorithms are:
- DES-CBC, 3DES-CBC, AES-CBC
- HMAC-SHA1, HMAC-MD5
non-CBC algorithm such as AES-GCM is not supported by CESA's acceleration
engine. mvcesa is still useful to implement such algorithms as combination of
accelerated block cipher and software chaining.
the buffer management(ex. fill the rx descriptors/buffers) is done by H/W in
ARMADA XP/380, and is done by S/W in ARMADA 370. the H/W BM support is not yet
implemented, so all devices use the S/W management mode at this time.
this driver supports 'counter mode', and is disabled by default.
ARMADA SoC family has new ethernet controller acceleration mode called
'enhanced mode' or 'counter mode.' it seems that backward compatibility mode
used by if_mvgbe is still working, but the specification of the old mode
is completely disappeared from SoC's reference manual.
I tested the driver using MIRABOX(ARMADA/370).
I had removed <sys/rnd.h> from files that didn't mention anything of
the rnd(9) API. But they included other files which assumed
<sys/rnd.h> had already been included.
designated initializers.
I have not built every extant kernel so I have probably broken at
least one build; however I've also found and fixed some wrong
cdevsw/bdevsw entries so even if so I think we come out ahead.
returns other than 0, the TX ring might not full. Check whether
the TX ring has one or more packets. If the ring is empty,
dont' set IFF_OACTIVE because an TX complete interrupt never
occur and IFF_OACTIVE flags is left. The interface's timer
isn't reset, so a device timeout desn't occur.
Fixes a bug that IFF_OACTIVE flag is left on heavy load.
Part of PR#48568.
