OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] [PATCH v4] content: Introduce VIRTIO_NET_F_STANDBY feature


On Wed, Dec 05, 2018 at 06:18:05PM +0200, Sameeh Jubran wrote:
> Hi all,
> 
> This is a followup on the discussion in the DPDK and Virtio monthly meeting.
> 
> Michael suggested that layer 2 tests should be created in order to
> test the PF/VF behavior in different scenarios without using VMs at
> all which should speed up the testing process.
> 
> The following "mausezahn" tool - which is part of netsniff-ng package
> - can be used in order to generate layer 2 packets as follows:
> 
> mausezahn enp59s0 -c 0 -a rand -b 20:71:c6:2a:68:38 "08 00 aa bb cc dd"
> 
> The packets can be sniffed using tcpdump or netsniff-ng.
> 
> I am not completely sure how the setup should look like on the host,
> but here is a script which assigns macvlan to the PF and sets it's mac
> address to be the same as the VF mac address. The scripts assumes that
> the sriov is already configured and the vf are present.
> 
> [root@wsfd-advnetlab10 ~]# cat go_macvlan.sh
> MACVLAN_NAME=macvlan0
> PF_NAME=enp59s0
> VF_NUMBER=1
> MAC_ADDR=20:71:c6:2a:68:38
> 
> echo "$PF_NAME vf status before setting mac"
> ip link show dev $PF_NAME
> ip link set $PF_NAME vf $VF_NUMBER mac $MAC_ADDR
> ip li add link $PF_NAME $MACVLAN_NAME address $MAC_ADDR type macvlan
> ip link set $PF_NAME up
> echo "$PF_NAME vf status after setting mac"
> ip link show dev $PF_NAME
> 
> Please share your thoughts on how the different test scenarios should
> go, I can customize the scripts further more and host them somewhere.

OK so for starters need code to send the packets (maybe
multiple ones with a counter so drops can be detected?)
and also to sniff and verify their arrival on either of
the two interfaces?

And then on top there would be all the different ways
to switch between the two interfaces back and forth
while this is going on.

The tool would ideally do this several times with each method and report
observed downtime.


-- 
MST


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]