07/04/2017 17:27, Andriy Berestovskyy: > Hey Thomas, > > On 07.04.2017 16:47, Thomas Monjalon wrote: > >> What if we add to the max_rx_pkt_len description: "the effective maximum > >> RX frame size depends on PMD, please refer the PMD guide for the > >> details"? > > > > I think the problem is not in the documentation but in the implementations > > which should be more consistent. > > The hardware is different, there is not much we can do about it.
We can return an error if the max_rx_pkt_len cannot be set in the NIC. > Nevertheless, we can fix the false comment and have a default for the > jumbos, which is beneficial for the apps/examples. The examples are using a hardcoded value, so they need to be fixed anyway. > > If I understand well, the inconsistency between drivers was already an > > issue before your patch. > > Your patch fixes an inconsistency in ethdev without fixing the drivers. > > We need to know if it is a good first step and if the drivers can be > > fixed later. > > Thomas, some of the examples use a hard-coded jumbo frame size, which is > too big for the underlaying PMDs, so those examples fail. The plan was > to fix them all with this commit in ethdev but I am not sure now you are > to accept the change. This ethdev patch is about a behaviour change of the API. It is about considering 0 as a request for default value and return an error if a value cannot be set. It will require more agreements and changes in the drivers for returning an error where appropriate. > It is important for us to have those examples working in the upcoming > release, do you think it is better to send fixes for those examples > instead of this commit then? The examples can be improved independently of this patch.