On 02/26/15 15:21, Mike Karels wrote:
I'm doing some work for Mellanox and we need some 100GBase types for
coming hardware products too.
I think we are not using the 32-bits of "ifm_media" well enough.
Has it been discussed to add more bits to "IFM_NMASK" and have more
ethernet types like IFM_ETHER_0, IFM_ETHER_1, IFM_ETHER_2, IFM_ETHER_3 ....
Currently 5 IFM types are defined. If 2 more bits can be added to
IFM_NMASK we have 5 bits total giving us 2**5 = 32 IFM types. Then it
should be possible to define "(32 - 5) * 32 = 864" more ethernet types,
which I think should be enough for now - or we add even one more bit to
IFM_NMASK ?
Did you have specific bits in mind? I'm fairly sure they are all assigned
to something now. The adjacent bits are used for the subtype/variant and
options. Most of the options are used, maybe not all.
I haven't checked whether the "instance" field is still used, though. It
was for MII PHY numbers, I believe.
If we had more bits, it seems better to put them directly into the subtype
field rather than the type field.
Mike
Hi,
There are 6 token ring bits, which I presume are available when token
ring is not selected.
#define IFM_TOK_ETR 0x00000200 /* Early token release */
#define IFM_TOK_SRCRT 0x00000400 /* Enable source routing features */
#define IFM_TOK_ALLR 0x00000800 /* All routes / Single route
bcast */
#define IFM_TOK_DTR 0x00002000 /* Dedicated token ring */
#define IFM_TOK_CLASSIC 0x00004000 /* Classic token ring */
#define IFM_TOK_AUTO 0x00008000 /* Automatic Dedicate/Classic
token ring */
Maybe these can be used for other purposes when the type is equal to
ethernet?
--HPS
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
