Re: how to fix an interesting issue with mountd?

[Rick Macklem]

Rodney Grimes wrote:
>> Hi,
>> 
>> I'm posting this one to freebsd-net@ since it seems vaguely similar
>> to a network congestion problem and thought that network types
>> might have some ideas w.r.t. fixing it?
>> 
>> PR#246597 - Reports a problem (which if I understand it is) where a sighup
>>is posted to mountd and then another sighup is posted to mountd while
>>it is reloading exports and the exports are not reloaded again.
>>--> The simple patch in the PR fixes the above problem, but I think will
>>   aggravate another one.
>> For some NFS servers, it can take minutes to reload the exports file(s).
>> (I believe Peter Erriksonn has a server with 8+ file systems exported.)
>> r348590 reduced the time taken, but it is still minutes, if I recall 
>> correctly.
Actually, my recollection w.r.t. the times was way off.
I just looked at the old PR#237860 and, without r348590, it was 16seconds
(aka seconds, not minutes) and with r348590 that went down to a fraction
of a second (there was no exact number in the PR, but I noted milliseconds in
the commit log entry.

I still think there is a risk of doing the reloads repeatedly.

>> --> If you apply the patch in the PR and sighups are posted to mountd as
>>often as it takes to reload the exports file(s), it will simply 
>> reload the
>>exports file(s) over and over and over again, instead of processing
>>Mount RPC requests.
>> 
>> So, finally to the interesting part...
>> - It seems that the code needs to be changed so that it won't "forget"
>>   sighup(s) posted to it, but it should not reload the exports file(s) too
>>   frequently.
>> --> My thoughts are something like:
>>   - Note that sighup(s) were posted while reloading the exports file(s) and
>> do the reload again, after some minimum delay.
>> --> The minimum delay might only need to be 1second to allow some
>>RPCs to be processed before reload happens again.
>>  Or
>> --> The minimum delay could be some fraction of how long a reload takes.
>>   (The code could time the reload and use that to calculate how long 
>> to
>>delay before doing the reload again.)
>> 
>> Any ideas or suggestions? rick
>> ps: I've actually known about this for some time, but since I didn't have a 
>> good
>>  solution...
>
>Build a system that allows adding and removing entries from the
>in mountd exports data so that you do not have to do a full
>reload every time one is added or removed?
>
>Build a system that used 2 exports tables, the active one, and the
>one that was being loaded, so that you can process RPC's and reloads
>at the same time.
Well, r348590 modified mountd so that it built a new set of linked list
structures from the modified exports file(s) and then compared them with
the old ones, only doing updates to the kernel exports for changes.

It still processes the entire exports file each time, to produce the in mountd
memory linked lists (using hash tables and a binary tree).

Peter did send me a patch to use a db frontend, but he felt the only
performance improvements would be related to ZFS.
Since ZFS is something I avoid like the plague I never pursued it.
(If anyone willing to ZFS stuff wants to pursue this,
just email and I can send you the patch.)
Here's a snippet of what he said about it.
>  It looks like a very simple patch to create and even though it wouldn’t 
> really>  improve the speed for the work that mountd does it would 
> make possible really >  drastic speed improvements in the zfs commands. They 
> (zfs commands) currently >  reads the thru text-based exports file multiple 
> times when you do work with zfs  >  filesystems (mounting/sharing/changing 
> share options etc). Using a db based  
>  exports file for the zfs exports (b-tree based probably) would allow the zfs 
> code > to be much faster.

At this point, I am just interested in fixing the problem in the PR, rick

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: how to fix an interesting issue with mountd?

[Rodney W. Grimes]

> Hi,
> 
> I'm posting this one to freebsd-net@ since it seems vaguely similar
> to a network congestion problem and thought that network types
> might have some ideas w.r.t. fixing it?
> 
> PR#246597 - Reports a problem (which if I understand it is) where a sighup
>is posted to mountd and then another sighup is posted to mountd while
>it is reloading exports and the exports are not reloaded again.
>--> The simple patch in the PR fixes the above problem, but I think will
>   aggravate another one.
> For some NFS servers, it can take minutes to reload the exports file(s).
> (I believe Peter Erriksonn has a server with 8+ file systems exported.)
> r348590 reduced the time taken, but it is still minutes, if I recall 
> correctly.
> --> If you apply the patch in the PR and sighups are posted to mountd as
>often as it takes to reload the exports file(s), it will simply reload 
> the
>exports file(s) over and over and over again, instead of processing
>Mount RPC requests.
> 
> So, finally to the interesting part...
> - It seems that the code needs to be changed so that it won't "forget"
>   sighup(s) posted to it, but it should not reload the exports file(s) too
>   frequently.
> --> My thoughts are something like:
>   - Note that sighup(s) were posted while reloading the exports file(s) and
> do the reload again, after some minimum delay.
> --> The minimum delay might only need to be 1second to allow some
>RPCs to be processed before reload happens again.
>  Or
> --> The minimum delay could be some fraction of how long a reload takes.
>   (The code could time the reload and use that to calculate how long 
> to
>delay before doing the reload again.)
> 
> Any ideas or suggestions? rick
> ps: I've actually known about this for some time, but since I didn't have a 
> good
>  solution...

Build a system that allows adding and removing entries from the
in mountd exports data so that you do not have to do a full
reload every time one is added or removed?

Build a system that used 2 exports tables, the active one, and the
one that was being loaded, so that you can process RPC's and reloads
at the same time.

> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: how to fix an interesting issue with mountd?

[Rick Macklem]

Updated slightly from the previous post...

Hi,

I'm posting this one to freebsd-net@ since it seems vaguely similar
to a network congestion problem and thought that network types
might have some ideas w.r.t. fixing it?

PR#246597 - Reports a problem (which if I understand it is) where a sighup
   is posted to mountd and then another sighup is posted to mountd while
   it is reloading exports and the exports are not reloaded again.
   --> The simple patch in the PR fixes the above problem, but I think will
  aggravate another one.
For some NFS servers, it can take minutes to reload the exports file(s).
(I believe Peter Erriksonn has a server with 8+ file systems exported.)
r348590 reduced the time taken, but it is still minutes, if I recall correctly.
--> If you apply the patch in the PR and sighups are posted to mountd as
   often as it takes to reload the exports file(s), it will simply reload 
the
   exports file(s) over and over and over again, instead of processing
   Mount RPC requests.
   The current code ignores sighup(s) posted while a reload is in progress,
   but could still suffer a similar fate if sighups are posted to mountd 
just
   after a reload completes, over and over..
   (I vaguely recall someone reporting that mountd spent hours just 
reloading
exports repeatedly.)

So, finally to the interesting part...
- It seems that the code needs to be changed so that it won't "forget"
  sighup(s) posted to it, but it should not reload the exports file(s) too
  frequently.
--> My thoughts are something like:
  - Note that sighup(s) were posted while reloading the exports file(s) and
do the reload again, after some minimum delay.
--> The minimum delay might only need to be 1second to allow some
   RPCs to be processed before reload happens again.
 Or
--> The minimum delay could be some fraction of how long a reload takes.
  (The code could time the reload and use that to calculate how long to
   delay before doing the reload again.)

Any ideas or suggestions? rick
ps: I've actually known about this for some time, but since I didn't have a good
 solution...
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

how to fix an interesting issue with mountd?

[Rick Macklem]

Hi,

I'm posting this one to freebsd-net@ since it seems vaguely similar
to a network congestion problem and thought that network types
might have some ideas w.r.t. fixing it?

PR#246597 - Reports a problem (which if I understand it is) where a sighup
   is posted to mountd and then another sighup is posted to mountd while
   it is reloading exports and the exports are not reloaded again.
   --> The simple patch in the PR fixes the above problem, but I think will
  aggravate another one.
For some NFS servers, it can take minutes to reload the exports file(s).
(I believe Peter Erriksonn has a server with 8+ file systems exported.)
r348590 reduced the time taken, but it is still minutes, if I recall correctly.
--> If you apply the patch in the PR and sighups are posted to mountd as
   often as it takes to reload the exports file(s), it will simply reload 
the
   exports file(s) over and over and over again, instead of processing
   Mount RPC requests.

So, finally to the interesting part...
- It seems that the code needs to be changed so that it won't "forget"
  sighup(s) posted to it, but it should not reload the exports file(s) too
  frequently.
--> My thoughts are something like:
  - Note that sighup(s) were posted while reloading the exports file(s) and
do the reload again, after some minimum delay.
--> The minimum delay might only need to be 1second to allow some
   RPCs to be processed before reload happens again.
 Or
--> The minimum delay could be some fraction of how long a reload takes.
  (The code could time the reload and use that to calculate how long to
   delay before doing the reload again.)

Any ideas or suggestions? rick
ps: I've actually known about this for some time, but since I didn't have a good
 solution...
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D24989: netinet: Generate a random RSS key on boot.

[neel_neelc.org (Neel Chauhan)]

neel_neelc.org added a comment.


  Should I sequence the key into "symmetrical RSS" where the first 32 bits == 
the next 32 bits, and all subsequent 16 bits chunks are equal?. Or is it 
something else?

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D24989/new/

REVISION DETAIL
  https://reviews.freebsd.org/D24989

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: neel_neelc.org, #csprng, markm
Cc: avg, markm, cem, #csprng, kevans, debdrup, rwatson, imp, ae, melifaro, 
#contributor_reviews_base, freebsd-net-list, mmacy, kpraveen.lkml_gmail.com, 
marcnarc_gmail.com, simonvella_gmail.com, novice_techie.com, 
tommi.pernila_iki.fi, krzysztof.galazka_intel.com
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Intel X553 driver Support for Freebsd 12.1

[Nrgia via freebsd-net]

Hello,

I am using the following board:
https://www.supermicro.com/en/products/motherboard/A2SDi-4C-HLN4F

and it uses Intel X553 chipset:
On FreeBSD 12.1 NETMAP is not working as it should
For example:

On FreeBSD 11.2 for example I achieved full speed only after I compiled my own 
driver, so I had:

- NETMAP native mode : 600 - 960 Mbs/s - with Intel compiled driver (forced by 
using dev.netmap.admode=1)
- NETMAP emulated mode: 150 Mb/s - with included FreeBSD driver

On FreeBSD 12.1 I have:

- Netmap native mode(at least that's what the system reports) : 150 Mbs/s - 
with included FreeBSD driver (forced by using dev.netmap.admode=1)
- Netmap emulated mode: 150 Mbs/s - with Intel driver compiled from Intel site, 
or from FreeBSD source: intel-ix-kmod

Also on linux works at full speed.

Some Information about my configuration:

1) The board is 
https://www.supermicro.com/en/products/motherboard/A2SDi-4C-HLN4F
2) The NIC are Lan on Board from Intel suing X553 chipset:

sysctl dev.ix.3:

dev.ix.3.iflib.driver_version: 4.0.1-k

dev.ix.3.%parent: pci7

dev.ix.3.%pnpinfo: vendor=0x8086 device=0x15e5 subvendor=0x8086 
subdevice=0x class=0x02

dev.ix.3.%location: slot=0 function=1 dbsf=pci0:8:0:1 
handle=\_SB_.PCI0.VRP1.LAN3

dev.ix.3.%driver: ix

dev.ix.3.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver.

On FreeBSD 11.2 in order to get full speed on this NICs, even without NETMAP 
enabled I used to compile the Intel driver from here:

[https://downloadcenter.intel.com/do...10-Gigabit-Network-Connections-Under-FreeBSD-](https://downloadcenter.intel.com/download/14688/Intel-Network-Adapters-Driver-for-PCIe-10-Gigabit-Network-Connections-Under-FreeBSD-)
but know if I do this, Netmap will not start in Native mode, because of the new 
iflib framework.

What can I do to make this work? Is there a new Intel driver that should fix 
this, 4.0.1-k that comes from upstream is not working.
I started a thread on FreeBSD forums here 
https://forums.freebsd.org/threads/intel-x553-driver-support-for-freebsd-12-1.75588/
 if you want to respond that way.

If you can please help.

Thank you

Sent with [ProtonMail](https://protonmail.com) Secure Email.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D24989: netinet: Generate a random RSS key on boot.

[neel_neelc.org (Neel Chauhan)]

neel_neelc.org added a comment.


  In D24989#552576 , @avg wrote:
  
  > I have a vague memory, maybe wrong, that commonly used fixed RSS keys were 
selected because they had some property (-ies).
  > So, maybe just being random is not good enough?
  > I think that hypothetical `rss_isbadkey` was mentioned for a reason?
  
  I Google searched this and haven't found much evidence on RSS keys. I could 
be wrong as well.

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D24989/new/

REVISION DETAIL
  https://reviews.freebsd.org/D24989

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: neel_neelc.org, #csprng, markm
Cc: avg, markm, cem, #csprng, kevans, debdrup, rwatson, imp, ae, melifaro, 
#contributor_reviews_base, freebsd-net-list, mmacy, kpraveen.lkml_gmail.com, 
marcnarc_gmail.com, simonvella_gmail.com, novice_techie.com, 
tommi.pernila_iki.fi, krzysztof.galazka_intel.com
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D24989: netinet: Generate a random RSS key on boot.

[neel_neelc.org (Neel Chauhan)]

neel_neelc.org added a comment.


  I believe Linux just uses random keys:
  
  - 
https://github.com/torvalds/linux/blob/29d9f30d4ce6c7a38745a54a8cddface10013490/net/ethtool/ioctl.c#L924
  
  Callers (example):
  
  - 
https://github.com/torvalds/linux/blob/29d9f30d4ce6c7a38745a54a8cddface10013490/drivers/net/ethernet/emulex/benet/be_main.c#L3728
  - 
https://github.com/torvalds/linux/blob/29d9f30d4ce6c7a38745a54a8cddface10013490/drivers/net/ethernet/emulex/benet/be_main.c#L3728
  
  However, DPDK uses something called "MAXIMALLY EQUIDISTRIBUTEDCOMBINED LFSR 
GENERATORS" (paper: 
https://www.ams.org/journals/mcom/1999-68-225/S0025-5718-99-01039-X/S0025-5718-99-01039-X.pdf):
  
  - 
https://github.com/DPDK/dpdk/blob/905a0c208267806f5e1f2021accec4302681e4a0/lib/librte_eal/common/rte_random.c#L131
  - Calls 
https://github.com/DPDK/dpdk/blob/905a0c208267806f5e1f2021accec4302681e4a0/lib/librte_eal/common/rte_random.c#L101
  
  Caller (example):
  
  - 
https://github.com/DPDK/dpdk/blob/c3d30e9d753ef3121c25b9403bf56ee09f2a2086/drivers/net/bnx2x/bnx2x.c#L6701

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D24989/new/

REVISION DETAIL
  https://reviews.freebsd.org/D24989

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: neel_neelc.org, #csprng, markm
Cc: avg, markm, cem, #csprng, kevans, debdrup, rwatson, imp, ae, melifaro, 
#contributor_reviews_base, freebsd-net-list, mmacy, kpraveen.lkml_gmail.com, 
marcnarc_gmail.com, simonvella_gmail.com, novice_techie.com, 
tommi.pernila_iki.fi, krzysztof.galazka_intel.com
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Netmap - Vale switch - tcp problem

[Vincenzo Maffione]

Hi Anthony,
  I think there is more than a bug, drivers-related, that show up when you
attach the interface to a vale switch.
I've found and fixed some related to if_vtnet (see below). In any case, in
my tests there is no difference between TCP traffic and other (UDP, ICMP,
STP,...).
The issues are not related to LRO, as I thought.
There are still more bugs in vtnet and I'm trying to chase them.
In the meanwhile it would help if you apply the patches below and try again
with vtnet to see if the situation improves. They apply cleanly to 12.1
release.

Regarding your problem with em devices, it is probably yet a different
issue. It may be related to the iflib transition or not. It would help to
try the same setup on stable/11 (which does not have iflib). I don't have
an em device, but I will try with an emulated em in QEMU/KVM.

Cheers,
  Vincenzo


r361698 | vmaffione | 2020-06-01 16:14:29 + (Mon, 01 Jun 2020) | 8 lines

netmap: if_vtnet: avoid netmap ring wraparound

netmap assumes the one "slot" is left unused to distinguish
the empty ring and full ring conditions. This assumption was
violated by vtnet_netmap_rxq_populate().

MFC after:  1 week


r361697 | vmaffione | 2020-06-01 16:12:09 + (Mon, 01 Jun 2020) | 8 lines

netmap: if_vtnet: replace vtnet_free_used()

The functionality contained in this function is duplicated,
as it is already available in vtnet_txq_free_mbufs()
and vtnet_rxq_free_mbufs().

MFC after:  1 week


r361696 | vmaffione | 2020-06-01 16:10:44 + (Mon, 01 Jun 2020) | 13
lines

netmap: vtnet: fix RX virtqueue initialization bug

The vtnet_netmap_rxq_populate() function erroneously assumed
that kring->nr_hwcur = 0, i.e. the kring was in the initial
state. However, this is not always the case: for example,
when a vtnet reinit is triggered by some changes in the
interface flags or capenable.
This patch changes the behaviour of vtnet_netmap_kring_refill()
so that it always starts publishing the netmap buffers starting
from the current value of kring->nr_hwcur.

MFC after:  1 week

Il giorno lun 1 giu 2020 alle ore 15:19 Anthony Arnaud <
antho.arnaudi...@gmail.com> ha scritto:

> Hi Vincenzo,
>
> To simplify the scenario I have installed from scratch FBSD12.1 on a new
> machine, without any virtualization env.
> I have encountered the same problem, when i attach an ethernet interface
> to vale switch (in this case an intel card em5) the tcp traffic disappears
> and tcpdump shown only udp, icmp6 and stp packets.
> If I detach the NIC from vale0 tcpdump shown all tcp traffic.
> I'm using the netmap version included in FBSD 12.1, and I have compiled
> vale-ctl presents in kernel sources (/src/tools/tools/netmap/)
> I executed your steps.
> There is something dark about that behaviour...
>
> Cheers
> Anthon
>
>
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Netmap - Vale switch - tcp problem

[Anthony Arnaud]

Hi Vincenzo,

To simplify the scenario I have installed from scratch FBSD12.1 on a new
machine, without any virtualization env.
I have encountered the same problem, when i attach an ethernet interface to
vale switch (in this case an intel card em5) the tcp traffic disappears and
tcpdump shown only udp, icmp6 and stp packets.
If I detach the NIC from vale0 tcpdump shown all tcp traffic.
I'm using the netmap version included in FBSD 12.1, and I have compiled
vale-ctl presents in kernel sources (/src/tools/tools/netmap/)
I executed your steps.
There is something dark about that behaviour...

Cheers
Anthon

Il giorno sab 30 mag 2020 alle ore 14:29 Vincenzo Maffione <
vmaffi...@freebsd.org> ha scritto:

>
>
> Il giorno ven 29 mag 2020 alle ore 19:01 Anthony Arnaud <
> antho.arnaudi...@gmail.com> ha scritto:
>
>> Hi Vincenzo,
>>
>> thanks for your hints!
>> I rebooted my guest FBSD 12.1 machine, and I have perfomed your steps
>>
>> #ifconfig vtnet1 -txcsum -rxcsum -tso4 -tso6 up promisc
>>
>> vtnet1:
>> flags=28943 metric
>> 0 mtu 1500
>>
>> options=6c04b8
>> ether 0e:bd:ec:7a:08:06
>> media: Ethernet 10Gbase-T 
>> status: active
>> nd6 options=29
>>
>> tcpdump is ok.
>>
>> Does it mean you see both ICMP, UDP and TCP traffic?
>
>
>> But after:
>>
>> #vale-ctl
>>
>> 446.196827 bdg_ctl [149] bridge:0 port:0 vale0:vtnet1
>> 446.196855 bdg_ctl [149] bridge:0 port:1 vale0:vtnet1^
>>
>> tcpdump not work anymore.
>>
>
> Do you see ICMP/UDP only and not TCP?
>
>
>> I don't understand why the tcp traffic disappears.
>> In my configuration vtnet1 is a mirror port created by Open vSwitch, but
>> I don't think that's the reason.
>>
>> No, I don't think that's relevant.
>
> In my setup, vtnet0 is a guest interface backed by a host tap device
> (attached to a linux bridge), and hypervisor is QEMU/KVM.
> Here are the steps I follow in the VM (in this order):
>
> # ifconfig vtnet0 -txcsum -rxcsum -tso4 -tso6 up 192.168.100.2/24
> # vale-ctl -h vale0:vtnet0
>
> # nc 192.168.100.1  # connect to listening netcat in the host.
> hello
> abc
> [...]
> # tcpdump -ni vtnet0 # This shows the TCP traffic.
>
> I start to see problems when I change the offloads:
> # ifconfig vtnet0 -lro
>
> Cheers,
>   Vincenzo
>
>
>> Below some info about my configuration:
>>
>> dev.netmap.iflib_rx_miss_bufs: 0
>> dev.netmap.iflib_rx_miss: 0
>> dev.netmap.iflib_crcstrip: 1
>> dev.netmap.bridge_batch: 1024
>> dev.netmap.default_pipes: 0
>> dev.netmap.priv_buf_num: 4098
>> dev.netmap.priv_buf_size: 2048
>> dev.netmap.buf_curr_num: 163840
>> dev.netmap.buf_num: 163840
>> dev.netmap.buf_curr_size: 2048
>> dev.netmap.buf_size: 2048
>> dev.netmap.priv_ring_num: 4
>> dev.netmap.priv_ring_size: 20480
>> dev.netmap.ring_curr_num: 200
>> dev.netmap.ring_num: 200
>> dev.netmap.ring_curr_size: 36864
>> dev.netmap.ring_size: 36864
>> dev.netmap.priv_if_num: 2
>> dev.netmap.priv_if_size: 1024
>> dev.netmap.if_curr_num: 100
>> dev.netmap.if_num: 100
>> dev.netmap.if_curr_size: 1024
>> dev.netmap.if_size: 1024
>> dev.netmap.ptnet_vnet_hdr: 1
>> dev.netmap.generic_rings: 1
>> dev.netmap.generic_ringsize: 1024
>> dev.netmap.generic_mit: 10
>> dev.netmap.generic_hwcsum: 0
>> dev.netmap.admode: 0
>> dev.netmap.fwd: 0
>> dev.netmap.txsync_retry: 2
>> dev.netmap.no_pendintr: 1
>> dev.netmap.no_timestamp: 0
>> dev.netmap.verbose: 0
>>
>>
>> dev.vtnet.1.txq0.rescheduled: 0
>> dev.vtnet.1.txq0.tso: 0
>> dev.vtnet.1.txq0.csum: 0
>> dev.vtnet.1.txq0.omcasts: 0
>> dev.vtnet.1.txq0.obytes: 0
>> dev.vtnet.1.txq0.opackets: 0
>> dev.vtnet.1.rxq0.rescheduled: 0
>> dev.vtnet.1.rxq0.csum_failed: 0
>> dev.vtnet.1.rxq0.csum: 66
>> dev.vtnet.1.rxq0.ierrors: 0
>> dev.vtnet.1.rxq0.iqdrops: 0
>> dev.vtnet.1.rxq0.ibytes: 11904780
>> dev.vtnet.1.rxq0.ipackets: 40984
>> dev.vtnet.1.tx_task_rescheduled: 0
>> dev.vtnet.1.tx_tso_offloaded: 0
>> dev.vtnet.1.tx_csum_offloaded: 0
>> dev.vtnet.1.tx_defrag_failed: 0
>> dev.vtnet.1.tx_defragged: 0
>> dev.vtnet.1.tx_tso_not_tcp: 0
>> dev.vtnet.1.tx_tso_bad_ethtype: 0
>> dev.vtnet.1.tx_csum_bad_ethtype: 0
>> dev.vtnet.1.rx_task_rescheduled: 0
>> dev.vtnet.1.rx_csum_offloaded: 0
>> dev.vtnet.1.rx_csum_failed: 0
>> dev.vtnet.1.rx_csum_bad_proto: 0
>> dev.vtnet.1.rx_csum_bad_offset: 0
>> dev.vtnet.1.rx_csum_bad_ipproto: 0
>> dev.vtnet.1.rx_csum_bad_ethtype: 0
>> dev.vtnet.1.rx_mergeable_failed: 0
>> dev.vtnet.1.rx_enq_replacement_failed: 0
>> dev.vtnet.1.rx_frame_too_large: 0
>> dev.vtnet.1.mbuf_alloc_failed: 0
>> dev.vtnet.1.act_vq_pairs: 1
>> dev.vtnet.1.requested_vq_pairs: 0
>> dev.vtnet.1.max_vq_pairs: 1
>> dev.vtnet.1.%parent: virtio_pci4
>> dev.vtnet.1.%pnpinfo:
>> dev.vtnet.1.%location:
>> dev.vtnet.1.%driver: vtnet
>> dev.vtnet.1.%desc: VirtIO Networking Adapter
>> dev.vtnet.0.txq0.rescheduled: 0
>>
>> Cheers,
>> Anthony
>>
>> Il giorno gio 28 mag 2020 alle ore 21:38 Vincenzo Maffione <
>> vmaffi...@freebsd.org> ha scritto:
>>
>>> Hi,
>>>   I was trying to reproduce your problem (same FreeBSD release as
>>> 

[Differential] D24989: netinet: Generate a random RSS key on boot.

[ae (Andrey V. Elsukov)]

ae added a comment.


  In D24989#552576 , @avg wrote:
  
  > I have a vague memory, maybe wrong, that commonly used fixed RSS keys were 
selected because they had some property (-ies).
  > So, maybe just being random is not good enough?
  > I think that hypothetical `rss_isbadkey` was mentioned for a reason?
  
  I also have such feeling. For example, you have some server that handles some 
serious workload, but after reboot due to the new key it will not be able to 
handle the same workload.

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D24989/new/

REVISION DETAIL
  https://reviews.freebsd.org/D24989

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: neel_neelc.org, #csprng, markm
Cc: avg, markm, cem, #csprng, kevans, debdrup, rwatson, imp, ae, melifaro, 
#contributor_reviews_base, freebsd-net-list, mmacy, kpraveen.lkml_gmail.com, 
marcnarc_gmail.com, simonvella_gmail.com, novice_techie.com, 
tommi.pernila_iki.fi, krzysztof.galazka_intel.com
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D24989: netinet: Generate a random RSS key on boot.

[avg (Andriy Gapon)]

avg added a comment.


  I have a vague memory, maybe wrong, that commonly used fixed RSS keys were 
selected because they had some property (-ies).
  So, maybe just being random is not good enough?
  I think that hypothetical `rss_isbadkey` was mentioned for a reason?

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D24989/new/

REVISION DETAIL
  https://reviews.freebsd.org/D24989

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: neel_neelc.org, #csprng, markm
Cc: avg, markm, cem, #csprng, kevans, debdrup, rwatson, imp, ae, melifaro, 
#contributor_reviews_base, freebsd-net-list, mmacy, kpraveen.lkml_gmail.com, 
marcnarc_gmail.com, simonvella_gmail.com, novice_techie.com, 
tommi.pernila_iki.fi, krzysztof.galazka_intel.com
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D24989: netinet: Generate a random RSS key on boot.

[markm (Mark R V Murray)]

markm requested changes to this revision.
markm added inline comments.
This revision now requires changes to proceed.

INLINE COMMENTS

> rss_config.c:251
>*/
> + arc4random_buf(rss_key, RSS_KEYSIZE);
>  }

This scares me less than the previously hard-coded key, but if we are going to 
the trouble to randomise, then we need to sequence it properly.

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D24989/new/

REVISION DETAIL
  https://reviews.freebsd.org/D24989

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: neel_neelc.org, #csprng, markm
Cc: markm, cem, #csprng, kevans, debdrup, rwatson, imp, ae, melifaro, 
#contributor_reviews_base, freebsd-net-list, mmacy, kpraveen.lkml_gmail.com, 
marcnarc_gmail.com, simonvella_gmail.com, novice_techie.com, 
tommi.pernila_iki.fi, krzysztof.galazka_intel.com
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"