2015-09-14 23:33, Marc Sune: > 2015-09-14 12:52 GMT+02:00 Morten Br?rup <mb at smartsharesystems.com>: > > This support function will be able to determine which speed is higher when > > exotic speeds are added to the bitmap. Please extend this conversion > > function to give three output parameters: speed, full/half duplex, auto > > negotiation/non-auto negotiation, or add two separate functions to get the > > duplex and auto-negotiation. > > Since, Full/Half duplex is for legacy 10/100Mbps only (afaik), I have my > doubts on using a bit for all speeds. I would suggest to define (unroll) > 100M (or 100M_FD) and 100M_HD, and the same 10Mbps/1gbps, as Thomas was > suggesting some mails ago. > > This was done in v4 (implicitely 100M == 100M_FD). See below.
Are we going to use DPDK for such low speeds? Maybe we can remove half duplex modes? [...] > So, as of v4 of this patch, there could be: a) autoneg any supported speed > (=> bitmap == 0) b) autoneg over group of speeds (=> more than one bit set > in the bitmap) c) forced speed (one and only one set in the bitmap). +1 [...] > * encode the link speed and duplex as of now, separating duplex and numeric > speed. I would suggest to add the encoded speed+duplex bitmap flag for > consistency (although redundant). > * or you return a single value, the bitmap with a single flag set of the > unrolled speeds, and then have the helpers int rte_eth_speed_from_bm(int > val_bm) and bool rte_eth_duplex_from_bm(int val_bm). Who has already used half duplex mode with DPDK?
