Re: [RFC] how to get real ifi_baudrate from network interface
On Thu, Sep 20, 2012 at 06:15:54AM +0400, Gleb Smirnoff wrote:
On Wed, Sep 19, 2012 at 02:16:17PM -0700, Maksim Yevmenkin wrote:
M hello,
M
M for sometime now i've been repeatedly annoyed by the fact that 10G
M interfaces lie about their ifi_baudrate. i would like to propose
M simple (hopefuly) change to address this.
M
M quick summary of the problem:
M
M struct if_data {
M ...
M u_char ifi_spare_char1;/* spare byte */
M u_char ifi_spare_char2;/* spare byte */
M ...
M u_long ifi_baudrate; /* linespeed */
M ...
M };
M
M as you can see ifi_baudrate is an u_long which is an arch specific
M type. on 32-bit arch it does not have enough bits to hold 10G line
M speed value (in bits per second)
M
M proposal
M
M we reuse one of the ifi_spare_char1 or ifi_spare_char2 bytes and
M re-purpose it as power factor to be applied to ifi_baudrate, i.e.
M
M real_ifi_baudrate = ifi_baudrate * 10 ** ifi_spare_char1
M
M obviously, 10G nic drivers will have to set ifi_spare_char1 to
M appropriate value, but it should not be a big deal. also, legacy tools
M that do not know about ifi_spare_char1 would continue to report
M wrong ifi_baudrate as they used to.
M
M any objections?
IMO, this is way to go for stable branches. In head it'll be better just
have uint64_t without any crutches.
You cannot do this in head either. It would break the libc exported ABI,
at least for getifaddrs(3). At least, the compat shims need to be provided,
but I suppose that breakage is much deeper.
pgpFQo3IdNbet.pgp
Description: PGP signature
Re: [RFC] how to get real ifi_baudrate from network interface
On Thu, Sep 20, 2012 at 1:34 AM, Konstantin Belousov
kostik...@gmail.com wrote:
On Thu, Sep 20, 2012 at 06:15:54AM +0400, Gleb Smirnoff wrote:
On Wed, Sep 19, 2012 at 02:16:17PM -0700, Maksim Yevmenkin wrote:
M hello,
M
M for sometime now i've been repeatedly annoyed by the fact that 10G
M interfaces lie about their ifi_baudrate. i would like to propose
M simple (hopefuly) change to address this.
M
M quick summary of the problem:
M
M struct if_data {
M ...
M u_char ifi_spare_char1;/* spare byte */
M u_char ifi_spare_char2;/* spare byte */
M ...
M u_long ifi_baudrate; /* linespeed */
M ...
M };
M
M as you can see ifi_baudrate is an u_long which is an arch specific
M type. on 32-bit arch it does not have enough bits to hold 10G line
M speed value (in bits per second)
M
M proposal
M
M we reuse one of the ifi_spare_char1 or ifi_spare_char2 bytes and
M re-purpose it as power factor to be applied to ifi_baudrate, i.e.
M
M real_ifi_baudrate = ifi_baudrate * 10 ** ifi_spare_char1
M
M obviously, 10G nic drivers will have to set ifi_spare_char1 to
M appropriate value, but it should not be a big deal. also, legacy tools
M that do not know about ifi_spare_char1 would continue to report
M wrong ifi_baudrate as they used to.
M
M any objections?
IMO, this is way to go for stable branches. In head it'll be better just
have uint64_t without any crutches.
You cannot do this in head either. It would break the libc exported ABI,
at least for getifaddrs(3). At least, the compat shims need to be provided,
but I suppose that breakage is much deeper.
thanks. so, i take it there is no objections to the proposed hack-ish
workaround? i understand that there is a desire to fix thing the
right way, but it involves breaking ABI. at least proposed hack-ish
workaround gets us somewhere. if no one objects, then i will put
workaround in.
thanks,
max
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] how to get real ifi_baudrate from network interface
On Wed, Sep 19, 2012 at 02:16:17PM -0700, Maksim Yevmenkin wrote:
M hello,
M
M for sometime now i've been repeatedly annoyed by the fact that 10G
M interfaces lie about their ifi_baudrate. i would like to propose
M simple (hopefuly) change to address this.
M
M quick summary of the problem:
M
M struct if_data {
M ...
M u_char ifi_spare_char1;/* spare byte */
M u_char ifi_spare_char2;/* spare byte */
M ...
M u_long ifi_baudrate; /* linespeed */
M ...
M };
M
M as you can see ifi_baudrate is an u_long which is an arch specific
M type. on 32-bit arch it does not have enough bits to hold 10G line
M speed value (in bits per second)
M
M proposal
M
M we reuse one of the ifi_spare_char1 or ifi_spare_char2 bytes and
M re-purpose it as power factor to be applied to ifi_baudrate, i.e.
M
M real_ifi_baudrate = ifi_baudrate * 10 ** ifi_spare_char1
M
M obviously, 10G nic drivers will have to set ifi_spare_char1 to
M appropriate value, but it should not be a big deal. also, legacy tools
M that do not know about ifi_spare_char1 would continue to report
M wrong ifi_baudrate as they used to.
M
M any objections?
IMO, this is way to go for stable branches. In head it'll be better just
have uint64_t without any crutches.
--
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
