Nicolas Droux wrote:
[EMAIL PROTECTED] wrote:
Nicolas Droux wrote:
> But back to the original question, when the driver does support
> them, how do I determine whether or not they are active with the
> current NIC?
In the past, we've discussed adding some way to see the driver's
capabilities through dladm. Some of this could be part of
Brussels, too.
We've discussed providing this as part of Crossbow as well, since we
make use of these features extensively, and the resulting
performance can vary depending on their availability.
Just to note there are at least two seperate pieces of information
that are of interest:
* what the NIC is capable of
* what the network interface has "turned on"
The challenge here is that some of these capabilities are always
"turned on" by the NIC, but they not might be in use by an upper layer
such as IP.
I've used the term "network interface" here to represent what is
turned on by IP. Or in other words, "network interface = ill".
It may also be worth adding:
* what the driver is capable of
and where relevant, it should be possible to manage ipv4 and ipv6
seperately.
Can you expand on that last sentence? I don't see the connection
you're trying to make between the IPv4/IPv6 management vs hardware
capabilities.
I was thinking more about what would be useful to us to be able
to turn on/off when testing software than what be useful in the
real world.
For example, if a driver is not yet mature, we might report that full
hardware
checksum offload is available (supported by the NIC) but it isn't
turned on
for foo0. Similarly, trying to enable it for foo0 would fail.
I'd rather have the driver not advertise the capability until it is
robust. Why would we want to advertise capabilities if they don't work?
When have you bought a NIC at a computer store that said it
supported any of these hardware accelleration features?
The point of advertising the features as present but unsupported
is one way i see of encouraging people who have hardware that
fits into this bucket to do something small but significant (make
that feature supported) that we might not do.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]