On 3/21/2017 1:56 PM, Shijith Thotton wrote:
> On Tue, Mar 21, 2017 at 01:01:58PM +0000, Ferruh Yigit wrote:
>> On 3/21/2017 12:53 PM, Shijith Thotton wrote:
>>> On Tue, Mar 21, 2017 at 12:24:49PM +0000, Ferruh Yigit wrote:
>>>> On 3/2/2017 11:32 AM, Shijith Thotton wrote:
>>>>> Signed-off-by: Shijith Thotton <shijith.thot...@caviumnetworks.com>
>>>>> Signed-off-by: Jerin Jacob <jerin.ja...@caviumnetworks.com>
>>>>> Signed-off-by: Derek Chickles <derek.chick...@caviumnetworks.com>
>>>>> Signed-off-by: Venkat Koppula <venkat.kopp...@caviumnetworks.com>
>>>>> Signed-off-by: Srisivasubramanian S <ssriniva...@caviumnetworks.com>
>>>>> Signed-off-by: Mallesham Jatharakonda <mjatharako...@oneconvergence.com>
>>>>
>>>> <...>
>>>>
>>>>>
>>>>> static int
>>>>> +lio_dev_change_vf_mtu(struct rte_eth_dev *eth_dev, uint16_t new_mtu)
>>>>> +{
>>>>> + struct lio_device *lio_dev = LIO_DEV(eth_dev);
>>>>> +
>>>>> + PMD_INIT_FUNC_TRACE();
>>>>> +
>>>>> + if (!lio_dev->intf_open) {
>>>>> + lio_dev_err(lio_dev, "Port %d down, can't change MTU\n",
>>>>> + lio_dev->port_id);
>>>>> + return -EINVAL;
>>>>> + }
>>>>> +
>>>>> + /* Limit the MTU to make sure the ethernet packets are between
>>>>> + * ETHER_MIN_MTU bytes and PF's MTU
>>>>> + */
>>>>> + if ((new_mtu < ETHER_MIN_MTU) ||
>>>>> + (new_mtu > lio_dev->linfo.link.s.mtu)) {
>>>>> + lio_dev_err(lio_dev, "Invalid MTU: %d\n", new_mtu);
>>>>> + lio_dev_err(lio_dev, "Valid range %d and %d\n",
>>>>> + ETHER_MIN_MTU, lio_dev->linfo.link.s.mtu);
>>>>> + return -EINVAL;
>>>>> + }
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>
>>>> Is this really sets the MTU?
>>>> "new_mtu" seems not used, except limit check, an lio_send_ctrl_pkt()
>>>> required perhaps?
>>>
>>> It won't set MTU for hardware and is possible only by PF. So
>>> lio_send_ctrl_pkt is not required. VF MTU is limited by PF MTU and is
>>> mentioned under limitations in driver documentation. Here we are
>>> allowing upper layer to set MTU up to the value configured by PF.
>>
>> I see, but lio_dev_change_vf_mtu() does not set anything at all. If it
>> is not modifying anything at all, why you claim "MTU update" supported?
>
> We allow update for the upper layer till the value supported by PF even
> though there are no real MTU update happening at hardware level.
> Thought it is ok to have it mentioned under limitation.
> Two options are:
> 1. mark support as partial.
> 2. remove this patch and support.
>
> Please suggest which one is better.
If I get it right, it is not possible to set VF MTU, so I would suggest
removing MTU update support.
But you may want to keep the patch for MTU validation, and change
function name according.
>
>>
>> And following logic seems wrong for this case:
>>
>> ...
>> if (lio_dev->linfo.link.s.mtu != mtu) {
>> ret = lio_dev_change_vf_mtu(eth_dev, mtu);
>> ...
>>
>> Should this functions set lio_dev->linfo.link.s.mtu at least, perhaps?
>
> lio_dev->linfo.link.s.mtu represents the MTU supported by the device and
> it gets updated if there is a change by PF.
So, "lio_dev->linfo.link.s.mtu" is device MTU set by PF, "mtu" is VF
eth_dev configured value.
If they are not same, lio_dev_change_vf_mtu() does check if "mtu" is in
valid range and return success or failure, right?
So, this is just configuration validation, nothing changed/set here.
>
>>
> <...>
>
