Re: [PATCH v4 4/4] dts: add test case that utilizes offload to pmd_buffer_scatter

["Juraj Linkeš" <juraj.linkes@pantheon.tech>]

>>>            with testpmd_shell as testpmd:
>>>                testpmd.set_forward_mode(TestPmdForwardingModes.mac)
>>> +            # adjust the MTU of the SUT ports
>>> +            for port_id in range(testpmd.number_of_ports):
>>> +                testpmd.set_port_mtu(port_id, 9000)
>>
>> For a second I thought about maybe somehow using the decorator from the
>> previous patch, but that only works with testpmd methods.
>>
>> But then I thought about us setting this multiple times (twice (9000,
>> then back to 1500) in each test case) and that a "better" place to put
>> this would be set_up_suite() (and tear_down_suite()), but that has a
>> major downside of starting testpmd two more times. Having it all in one
>> place in set_up_suite() would surely make the whole test suite more
>> understandable, but starting testpmd multiple times is not ideal. Maybe
>> we have to do it like in this patch.
> 
> Right, I ended up putting it here just because the shell was already
> started here so it was convenient, but setting the MTU and resetting
> it multiple times is also definitely not ideal. I'm not really sure of
> exactly the best way to handle it either unfortunately. Something else
> I could do is have my own boolean that just tracks if the MTU has been
> updated yet and only do it the first time, but then there would have
> to be some kind of way to track which case is the last one to run
> which is also a whole can of worms. I think overall the cost of
> switching MTUs more than we need to is less than that of starting
> testpmd 2 extra times with only these two test cases, but if more are
> added it could end up being the opposite.
> 
> As a note though, from what I have recently seen while testing this,
> this change of MTU seems like it is generally needed when you are
> bound to the kernel driver while running DPDK instead of vfio-pci. One
> of the parameters that is passed into testpmd in this suite is
> --max-pkt-len and this adjusts the MTU of the ports before starting
> testpmd. However, since some NICs use the kernel driver as their
> driver for DPDK as well, this is not sufficient in all cases since the
> MTU of the kernel interface is not updated by this parameter and the
> packets still get dropped.  So, for example, if you start testpmd with
> a Mellanox NIC bound to mlx5_core and the parameter
> --max-pkt-len=9000, the MTU of the port when you do a `show port info
> 0` will be 8982, but if you do an `ip a` command you will see that the
> network interface still shows an MTU value of 1500 and the packets
> will be dropped if they exceed the MTU set on the network interface.
> In all cases the MTU must be higher than 2048, so I set it using
> testpmd to be agnostic of which driver you are bound to, as long as it
> is a DPDK driver.
> 
> I'm not sure if this is a bug or intentional because of something that
> blocks the updating of the network interface for some reason, but it
> might be worth mentioning to testpmd/ethdev maintainers regardless and
> I can raise it to them. If the `--max-pkt-len` parameter did update
> this MTU or always allowed receiving traffic at that size then we
> would not need to set the MTU in any test cases and it would be
> handled by testpmd on startup. In the meantime, there has to be this
> manual adjustment of MTU for the test cases to pass on any NIC that
> runs DPDK on its kernel driver.
> 

This is interesting. So the "--max-pkt-len" parameter doesn't set the 
MTU in kernel if bound to a kernel driver, but the testpmd command 
("port config mtu {port_id} {mtu}") does that properly?
The most obvious thing to think would be that both should be configuring 
the command the same way. In that case, it sound like some sort of race 
condition when starting testpmd. Or something has to be done differently 
when setting MTU during init time, in which case it's not a bug but we 
should try to understand the reason. Or it could be something entirely 
different. We should talk to the maintainers or maybe look into testpmd 
code to figure out whether there's a difference in how the two ways differ.

>>
>> I also noticed that we don't really document why we're setting MTU to
>> 9000. The relation between MTU and mbuf size (I think that relation is
>> the reason, correct me if I'm wrong) should be better documented,
>> probably in set_up_suite().
> 
> It isn't as much to do with the relation to the mbuf size as much as
> it is to test the scattering of packets you have to send and receive
> packets that are greater than that mbuf size so we have to increase
> the MTU to transmit those packets. Testpmd can run with the given
> parameters (--mbuf-size=2048, --max-pkt-len=9000, or both together)
> without the MTU change, but as I alluded to above, the MTU in testpmd
> isn't always true to what the network interface says it is.
> 

That's basically what I meant by relation between MTU and mbuf size :-). 
Let's put a clear reason for increasing the MTU into the set_up_suite 
docstring: that it must be higher than mbuf so that we're receiving 
packets big enough that don't fit into just one buffer. We currently 
just say we need to "support larger packet sizes", but I'd like to be 
more explicit with a reason for needing the larger packet size and how 
large the packets actually need to be, as it may not be obvious, since 
we're setting MTU way higher than 2048 (+5).

>>
>>>                testpmd.start()
>>>
>>>                for offset in [-1, 0, 1, 4, 5]:
>>> -                recv_payload = self.scatter_pktgen_send_packet(mbsize + offset)
>>> -                self._logger.debug(
>>> -                    f"Payload of scattered packet after forwarding: \n{recv_payload}"
>>> -                )
>>> +                recv_packets = self.scatter_pktgen_send_packet(mbsize + offset)
>>> +                self._logger.debug(f"Relevant captured packets: \n{recv_packets}")
>>> +
>>>                    self.verify(
>>> -                    ("58 " * 8).strip() in recv_payload,
>>> +                    any(
>>> +                        " ".join(["58"] * 8) in hexstr(pakt.getlayer(2), onlyhex=1)
>>> +                        for pakt in recv_packets
>>> +                    ),
>>>                        "Payload of scattered packet did not match expected payload with offset "
>>>                        f"{offset}.",
>>>                    )
>>> +            testpmd.stop()
>>
>> This sneaked right back in.
> 
> It did, but this time it actually is needed. With the MTU of ports
> being reset back to 1500 at the end of the test, we have to stop
> packet forwarding first so that the individual ports can be stopped
> for modification of their MTUs.

Oh, we can't modify the MTU while the port is running. I missed that, 
thanks.