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

[Morten Brørup]

Very valid question, Thomas. It's always a good idea to take a step back and look at the bigger picture!

Unfortunately, I can mention at least one company that has network appliances in production using such low speeds, and even half duplex: ours (SmartShare Systems). Basing our appliances on DPDK does not change this situation.

When you ship a lot of network appliances to a variety of customers, some of the appliances will eventually end up at customers who connects one of the ports to some equipment which is either very old, or which is configured for forced speed/duplex due to their old IT policy which hasn't been updated for decades. With a sufficient number customers, you are going to see everything possible! Reality surpasses imagination.


Med venlig hilsen / kind regards
- Morten Brørup

-----Original Message-----
From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] 
Sent: 15. september 2015 09:05
To: Marc Sune
Cc: Morten Brørup; Nélio Laranjeiro; dev at dpdk.org; Olga Shern; Adrien Mazarguil
Subject: Re: [dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap

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?