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.
>
> 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.
>
<...>
