Sebastien Roy wrote:
> I'm in the process of writing the PSARC fast-track which will update UV
> given the fast-path and code-review developments, and there is one thing
> sticks out at me while writing it. I think it would be addressed with a
> very minor update to the code (which I could do within minutes if need be.)
>
> The issue is that we have a new m_dev field in mac_register_t which only
> the sofmac module can fill in. This is awkward to me since we now have a
> project-private field in a (to-be) public structure. We also have a
> project-private MAC_CAPAB_LEGACY MAC capability which was designed to
> return information specific to softmac. It would seem entirely
> appropriate to me to return this dev_t as part of the capability data for
> this capability.
>
> Thoughts?
This is what I have so far. Have I missed anything? Note that I
included my suggestion above in section 2.2, but let me know if there are
objections to this.
An additional question from me is, does the removal of the fast-path also
necessitate the removal of MAC_CAPAB_MDT? I was under the impression
that we could still make use of MAC_CAPAB_MDT without a fast-path, yet it
was ripped out of clearview-uv along with the fast-path.
Also, we obviously won't be filing anything until we have satisfactory
performance results from both the non-fast-path and new-fast-path code.
1. Summary
This case comprises pre-integration updates to Clearview Nemo
Unification and Vanity Naming, currently described in the following
PSARC cases:
2006/499 Clearview Nemo unification and vanity naming
2007/527 Addendum for Clearview Vanity Naming and Nemo Unification
2. Details
2.1 Removal of Data Fast-Path for Softmac
In the design described in 2006/499, the softmac kernel module is
responsible for representing "legacy" DLPI devices to the Nemo
framework, and ensuring that data packets flow properly between DLPI
streams above Nemo and the "legacy" drivers underneath. This called
for a fast-path between upper DLPI streams and lower "legacy" drivers,
implemented by having the softmac module open a stream to the
underlying driver for each upper stream above Nemo, and linking these
streams to bypass Nemo entirely. The fast-path is referred to as the
"perstream" past-path in the design document.
This fast-path has been removed in the final phases of development.
For the initial UV putback, data packets will flow through the Nemo
framework as with any other Nemo driver.
The result is that the following interfaces will _not_ be delivered by
the UV putback as initially specified by the stated PSARC cases:
* MAC_CAPAB_TX_LOOPBACK (2006/499, Project Private)
* MAC_CAPAB_PUTNEXT_TX (2006/499, Project Private)
* MAC_CAPAB_MDT (2006/499, Project Private) XXX
* MAC_CAPAB_PERSTREAM (2006/499, Project Private)
* mac_perstream_open() and mac_perstream_close() (2006/499, Project
Private)
* MAC_CAPAB_NO_NATIVEVLAN (2007/527, Consolidation Private)
2.2 MAC_CAPAB_LEGACY MAC Capability (Project Private)
This capability replaces MAC_CAPAB_NOLINK_UPDATE defined in 2006/499,
and provides additional information. The data for this capability is
a pointer to the following structure:
typedef struct mac_capab_legacy_s {
dev_t mcl_dev;
uint32_t mcl_unsup_note;
} mac_capab_legacy_t;
The ml_dev field is set to the dev_t of the underlying "legacy"
device. This is used by the mac module to force the underlying device
to attach when a MAC client calls mac_open().
The ml_unsup_notif field is a bitfield of MAC capabilities. Certain
"legacy" devices under softmac may not support the DLPI notifications
needed for softmac to provide all MAC notifications to the Nemo
framework. The softmac module fills in this field with the set of MAC
notifications that are not supported by the given softmac instance.
-Seb
