SMB signing also has a large impact on windows servers, I have heard at least one story from the trenches about clients enabling smb signing with windows patches and the poor bewildered windows server operator wondering why his servers are suddenly so overloaded. So, I would imagine adding encryption would have a significant overhead. You might feel lucky that you know the cause and how to prevent it. I would say it all depends on what the other 70% of your cpu is doing. Also, assuming traffic does not increase alot with a faster filer, the percentage would most likely decrease.
To be clear, SMB signing is exactly what it says -- a signature, not encryption.
The SMB MAC is essentially an MD5 of { key | SMB packet }. If you think something is odd with NetApp's implementation and you have access to similar hardware it wouldn't be difficult to construct a test case.
MD5 is CPU intensive, which is no surprise if you look at the code for it. On my desktop Linux box (Intel P4 1.60GHz) I ran this test of MD5:
time dd if=/dev/zero bs=10240 count=51200 | openssl md5 -hex
51200+0 records in 51200+0 records out d8b61b2c0025919d5321461045c8226f 5.56s real 4.78s user 0.75s system
Then I simply counted the bytes with wc:
time dd if=/dev/zero bs=10240 count=51200 | wc -c
51200+0 records in 51200+0 records out 524288000 0.81s real 0.10s user 0.69s system
So it took about 50 times as much CPU to compute the MD5 checksum as it did to simply count the bytes.
SMB signing could use even more CPU than this test because a MD5 checksum is computed for each SMB packet. In my test only one checksum is computed for one very large input rather than many checksums for many small inputs.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support