static inti40evf_dev_mtu_set
<https://code.dpdk.org/dpdk/v19.11/ident/i40evf_dev_mtu_set>(struct
rte_eth_dev <https://code.dpdk.org/dpdk/v19.11/ident/rte_eth_dev>
*dev, uint16_t mtu){
struct i40e_vf <https://code.dpdk.org/dpdk/v19.11/ident/i40e_vf> *vf
= I40EVF_DEV_PRIVATE_TO_VF
<https://code.dpdk.org/dpdk/v19.11/ident/I40EVF_DEV_PRIVATE_TO_VF>(dev->data->dev_private);
struct rte_eth_dev_data
<https://code.dpdk.org/dpdk/v19.11/ident/rte_eth_dev_data> *dev_data =
vf->dev_data;
uint32_t frame_size
<https://code.dpdk.org/dpdk/v19.11/ident/frame_size> = mtu +
I40E_ETH_OVERHEAD
<https://code.dpdk.org/dpdk/v19.11/ident/I40E_ETH_OVERHEAD>;
int ret = 0;
/* check if mtu is within the allowed range */
if (mtu < RTE_ETHER_MIN_MTU
<https://code.dpdk.org/dpdk/v19.11/ident/RTE_ETHER_MIN_MTU> ||
frame_size <https://code.dpdk.org/dpdk/v19.11/ident/frame_size> >
I40E_FRAME_SIZE_MAX
<https://code.dpdk.org/dpdk/v19.11/ident/I40E_FRAME_SIZE_MAX>)
return -EINVAL;
/* mtu setting is forbidden if port is start */
if (dev_data->dev_started) {
PMD_DRV_LOG
<https://code.dpdk.org/dpdk/v19.11/ident/PMD_DRV_LOG>(ERR,
"port %d must be stopped before configuration",
dev_data->port_id
<https://code.dpdk.org/dpdk/v19.11/ident/port_id>);
return -EBUSY;
}
if (frame_size <https://code.dpdk.org/dpdk/v19.11/ident/frame_size> >
RTE_ETHER_MAX_LEN
<https://code.dpdk.org/dpdk/v19.11/ident/RTE_ETHER_MAX_LEN>)
dev_data->dev_conf.rxmode.offloads |=
DEV_RX_OFFLOAD_JUMBO_FRAME
<https://code.dpdk.org/dpdk/v19.11/ident/DEV_RX_OFFLOAD_JUMBO_FRAME>;
else
dev_data->dev_conf.rxmode.offloads &=
~DEV_RX_OFFLOAD_JUMBO_FRAME
<https://code.dpdk.org/dpdk/v19.11/ident/DEV_RX_OFFLOAD_JUMBO_FRAME>;
dev_data->dev_conf.rxmode.max_rx_pkt_len = frame_size
<https://code.dpdk.org/dpdk/v19.11/ident/frame_size>;
return ret;}
On Wed, Oct 6, 2021 at 11:38 PM PRANAB DAS <pkdas.bos...@gmail.com> wrote:
> Hi,
>
> This is the code snippet from DPDK 19.11 i40evf PMD on setting mtu which
> would fail if port/device is already started. Does vppctl set interface mtu
> command stops, sets mtu and then starts the device or is this NIC specific?
> What is the approach or advice dealing with NIC specific limitations or
> quirk?
>
> Appreciate your feedback
>
> Thank you
>
> - Pranab K Das
>
>
>
> On Wed, Oct 6, 2021 at 5:34 PM PRANAB DAS via lists.fd.io <pkdas.boston=
> gmail....@lists.fd.io> wrote:
>
>> Hi
>>
>> We noticed that after an interface (physical
>> interface VirtualFunctionEthernet0/7/0) is up state
>> (vppctl set interface state <ifname> up), if we modify the mtu of the
>> interface (e.g. vppctl set interface <ifname> mtu 1500) the interface
>> starts doing rx-miss forever. The interface becomes completely blocked and
>> is not transient. It is possible that the interface is receiving and
>> transmitting packets while mtu is being altered from default 8000 to 1500.
>>
>> This occurs with i40e VF interfaces and VPP 20.05. I am wondering if this
>> is observed by others as well. It is not clear from the documentation
>> (either DPDK or VPP) if an interface needs to be in "down" (link down)
>> state before the mtu can be modified. The VPP document does say it programs
>> the NIC but does not clearly state if the interface must be in down state.
>> The DPDK rte_dev_ether_set_mtu() API does not mention any such restriction
>> either.
>>
>> I am wondering if this is specific to i40e VF only or applies for other
>> NIC as well.
>> What's the recommended way of updating mtu? If we modify the mtu of
>> logical/sub interface (e.g. VirtualFunctionEthernet0/7/0.400) will alter
>> the mtu of the physical interface ( VirtualFunctionEthernet0/7/0) as well.
>> How could we ensure that mtu setting is consistent on a VF which might have
>> multiple sub interfaces in use including the raw physical interface
>> (without any VLAN)
>>
>> I would really appreciate it if you could provide some advice in this
>> regard. We use physical interface (e.g. VirtualFunctionEthernet0/7/0) for
>> internal communication between two applications since memif is not high
>> performance and use sub interfaces (VirtualFunctionEthernet0/7/0.400, 500,
>> 600) for external networks.
>>
>> Thank you very much
>>
>> - Pranab K Das
>>
>>
>>
>>
>>
>>
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20290): https://lists.fd.io/g/vpp-dev/message/20290
Mute This Topic: https://lists.fd.io/mt/86131320/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
