[dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap

Thomas Monjalon thomas.monjalon at 6wind.com
Tue Sep 15 09:05:25 CEST 2015


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?


More information about the dev mailing list