Cathy Zhou wrote:
But this would need renaming the net1(bge1000) to another name first
because the system won't allow two links have the conflicting link
names. And this renaming operation needs to stop the snooping. "The
rename will fail if the link is currently in use."
I wasn't concerned about snoop being active when the rename happens.
I was concerned about the case when you have a user with the privilege
to snoop that is told to that "his" interface to check is called "net1"
and an administrator that changes what net1 is.
Next day when the user comes in and continues to use snoop to debug/tune
their application, the snoop output is different than it was the day before.
The APIs in section 7.2.5 explicitly expose that M_CTL messages are used
to carry IPsec information. I think we want to retain the flexibility to
change the way the IPsec information is carried to a NIC, so I would
recommend that the APIs be changed so that the da_ipsec_t is carried as
a separate argument to the send and receive functions. This adds a bit
of extra overhead in softmac, since it needs to convert between this
extra argument and the pre-pended M_CTL, but it means that GLDv3 drivers
with IPsec acceleration don't constrain our ability to replace the M_CTL
hack down the road. (For example, adding a m_tx_ipsec() function that
takes a dl_ipsec_t as an extra argument, and similarly on the receive
side.)
You mean on both receive-side and transmit-side, right? Sure.
Yes.
If I know I'm using link name net1, then I can find the device name
using dladm.
Yes.
And then can I use 'ls -l /dev/<devicename> to see the
physical path name?
No. Vanity naming compoment will not change anything under the /dev
namespace, therefore, for those devices only create DLPI style 2 device
nodes, there will be no /dev/<devicename> node. "ls -l
/dev/net/linkname" will not help either, as it only displays the "dev_t"
of the device with which the application can access the specified link.
For exmaple, ls /dev/net nodes of legacy devices will only displays the
corresponding softmac node.
So once I've used dladm to discover that link name "net1" has a device
name of bge17, can I use the existing techniques to map "bge17" to a
physical path name? E.g., today I can use
ls -l /dev/bge17
to find the physical path name in /devices/
In section 3.1.4, does the order between the cfgadm -c configure PCI8,
and dladm rename-link ce0 net0, matter?
It doesn't matter. Both order will work.
Good.
It probably makes sense to state that in the document.
Is there an assumption that when the ce0 replaces bge0, that the system
automatically propagate information to the new one? By this I mean the
fact that the users of net0 might have joined some set of multicast
groups, others might have the device in promiscuous mode, and we might
have IPsec state in the driver.
But by the time when ce0 replaces bge0, the hardware of net0 ((bge0
card) is already disconnected from the system. Therefore, the problem
you mentioned is not a issue.
So the underlying assumption is that before the replacement, something
has quiesced the use of bge0? That is, something has done an ifconfig
net0 unplumb?
Section 4.3.4 autopush. It isn't clear from the document whether this is
"just" a way to specify autopush using a link name, but that it
otherwise has all the limitations of autopush. For instance, a user
could reasonably ask whether autopush would apply to a currently used
link name, or what it would take for the new autopush configuration to
be applied. I'm assuming one would need to do an ifconfig unplumb and
ifconfig plumb for the new information to be applied.
That is correct.
If that's the
case, would it make sense for autopush -m to fail if the link name is in
use?
Actually, the dladm autopush subcommand is intentionally designed to
work the same way as autopush(1M) as I think administrators might want a
similiar administrative experience. That is, the autopush -m subcommand
will succeed if the link is in use, or even the specified link doesn't
exist.
It probably makes sense to be very explicit about these limitations in
the design document, so that it will be explicit in the user documentation.
Even if it is the same limitations that autopush(1m) has, dladm adds
credibility to the use of autopush, hence a new set of adminstrators
might start using dladm autopush and be surprised by the limitations.
Section 6.2.4 last paragraph says that "administrators will run dladm
create-vlan -l net0". But is this the case even if a VLAN was explicitly
created before the rename? For example, if the administrator does
dladm create-vlan -l bge0 -v 23 net12
dladm rename-link -l bge0 foo3
does the administrator have to do something to (re)create net12, or does
net12's existence survive the rename?
net12 will survive the rename. It is stated in page 31:
"Note that VLANs and aggregations associated with the renamed link are
created over the link's corresponding MAC in the kernel, and their
persistent link configuration will only refer to the linkid, which will
never change. Therefore, the rename operation will not affect the
traffic over the relevant VLANs or aggregations, nor their persistent
link configuration."
It might make sense to say something about that in 6.2.4 as well. E.g.
adding "but a VLAN created before the rename will not be affected by the
rename operation".
Section 6.3.1 talks about how softmac generates devices. But it doesn't
fully specify how different legacy devices are handled. In terms of
presence in /dev, we have at least 3 different types of legacy drivers:
1. Those that only do style 2, hence have only a /dev/foo which is a
like to a pseudo entry in /devices
2. Those that support both style 1 and style 2, with a /dev/foo as well
as /dev/foo<N>.
3. Those that only support style 1. (I haven't see any such devices, but
I haven't looked for them either).
In particular, for #1, I don't see how softmac would know what instances
exist, since there is only a pseudo node. How would softmac know to
create /dev/net/ce0 and /dev/net/ce1 when two ce cards are in the system?
One of the input parameters of the device's postattach function is
dacf_infohdl_t, which carries the device's "dip" information. So it
doesn't matter whether the device only has style-1 or style 2, or both
node.
ok
Good suggestion. But for legacy drivers which cannot support
M_MULTIDATA, softmac still needs to transform M_MULTIDATA messages into
M_DATA messages, and there are already several Nemo drivers who don't
understand M_MULTIDATA message format. What we can do is that the GLDv3
framework can first check whether m_multitx() function is non-NULL for
the MAC being registered, if yes, calls the m_multitx() function,
otherwise, does the transforming and calls m_tx().
Makes sense.
I assume that with DLPI drivers there is also a way (DL_CAPABILITY_REQ?)
that softmac can tell whether the driver support M_MULTIDATA.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
