On 8/8/2022 4:03 PM, Stephen Hemminger wrote:
> On Mon, 8 Aug 2022 16:49:44 +0200
> Francesco Mancino wrote:
>
>> eth_dev_validate_mtu, introduced in 990912e676e, validates configured
>> MTU plus overhead against max_rx_pktlen.
>> Since TAP is a virtual device, it should support as big MTU as pos
Interesting, did not know about that attribute.
Tested some tap devices on my machine and get a maxmtu value close to
max uint16, way bigger than RTE_ETHER_MAX_JUMBO_FRAME_LEN.
I do not know if will have time to code and test using netlink to set this
limit,
for the time being i think RTE_ETHER_
On Mon, 8 Aug 2022 17:38:21 +0200
Francesco Mancino wrote:
> Thank you for the feedback.
>
> I am sorry for the email spam, it was a learning process.
>
> I am not sure what results we would get by querying the MTU
> before configuring it, since we can (and do) set the MTU using
> SIOCSIFMTU.
Thank you for the feedback.
I am sorry for the email spam, it was a learning process.
I am not sure what results we would get by querying the MTU
before configuring it, since we can (and do) set the MTU using
SIOCSIFMTU.
On 2022-08-08 17:03, Stephen Hemminger wrote:
> On Mon, 8 Aug 2022 16:49:4
On Mon, 8 Aug 2022 16:49:44 +0200
Francesco Mancino wrote:
> eth_dev_validate_mtu, introduced in 990912e676e, validates configured
> MTU plus overhead against max_rx_pktlen.
> Since TAP is a virtual device, it should support as big MTU as possible.
>
> Signed-off-by: Francesco Mancino
d
5 matches
Mail list logo
