tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ifconfig v2



>> Maybe some of them could be merged, e.g. when you have ip4csum-rx,
>> ip4csum-tx print ip4csum (ifconfig accepts this as input).
> I like the idea of combining the keywords that way, but even with
> compression, the capabilities and enables take at least 4 out of 9
> lines in a fairly normal default display:

> wm0: flags < up, running >
>         capabilities:   ip4csum, tcp4csum, tcp6csum, tso4, tso6,
>                         udp4csum, udp6csum
>         enabled: <none>
>         ether capabilities: vlan-mtu, vlan-hwtagging, jumbo-mtu
>         ether enabled: <none>

This could easily be compressed by doing something like printing the
capabilities with or without a -, the way ifconfig accepts them:

# ifconfig wm0 ip4csum -tcp4csum
# ifconfig wm0
        capabilities: ip4csum -tcp4csum ...

> I am pretty sure that most of the time, people are not looking for
> the capabilities/enables in the ifconfig output.

"Most of the time", people are looking for one particular piece of
information, and all the rest iis ignorable.  The problem is, it's hard
to predict what that one piece is.

It's perhaps arguable that there should be one command to report
addresses, one command to report flags, one command to report
capabilities, one command to report media, etc - or perhaps different
flags to a single command.

It's just a question of where to draw the "this is too far in this
direction, that's too far in that direction" lines.  I think the
current design is a not-horrible drawing of those lines; while some of
the lines could be pushed around a bit, I don't think it's a big deal.

> Ordinarily a driver should enable the offload capabilities that are
> known to work reliably, and it should not advertise the buggy ones.

Yes and no.  Since things like checksum offload - and even more so TCP
segmentation offload - break tcpdump (or equivalent)'s ability to see
the packets as they actually appear on the wire, I think it should be
possible to turn them off without having to compile a custom kernel
without them (in which case they end up permanently off, too).

Or do offload-capable drivers report on-the-wire packets back up to the
host after the offloaded operations have happened?  That doesn't match
my own experience, but that experience is relatively minimal.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index