On 3/10/2018 12:37 AM, Hyong Youb Kim wrote:
> On Fri, Mar 09, 2018 at 03:57:46PM +0000, Ferruh Yigit wrote:
>> On 3/9/2018 3:51 PM, Ananyev, Konstantin wrote:
>>>> Is this work based on an application that uses max_rx_pkt_len and to make
>>>> compatible with that application? If so we can continue with patch, but if
>>>> patch is to implement DPDK properly I suggest postponing this until
>>>> max_rx_pkt_len clarified.
>>> I think there are quite a lot apps these days that might rely on setting
>>> MTU via
>>> I think we need to support them till we (ever) deprecate
>> Right. I was trying to save effort in case something changes related
>> max_rx_pkt_len, but since it is not clear yet, will continue with this patch.
> testpmd has a command to change max_rx_pkt_len, a few DTS test cases
> rely on this feature to see if packets of certain sizes get dropped,
> and so on. We worked on this patch to support these cases.
> I prefer using only MTU, to follow the convention of most (all?)
> OSes. Though, this feature (max_rx_pkt_len) seems to come straight
> from an Intel 82599 feature. In its datasheet, see "126.96.36.199.13 Max
> Frame Size -- MAXFRS". Like to understand use cases for that, if
> anyone can share.
ixgbe driver updates MAXFRS register in ixgbe_dev_mtu_set(), so mtu seems can
MAXFRS is for rx only, from datasheet description of it:
"This value has no effect on transmit frames; it is the responsibility of
software to limit the size of transmit frames"
This may be the reason a new variable has been created for rx_frames, to
differentiate it from mtu. Not sure if max rx and tx size can be different
values for ixgbe.