Re: [Nfs-ganesha-devel] 'missed' recv with 2.6-rc2?

It's already in ntirpc, and we'll submit a pullup for this week. Daniel On 01/29/2018 12:53 PM, Pradeep wrote: Hi Bill, Are you planning to pull this into the next ganesha RC? Thanks, Pradeep On Sun, Jan 28, 2018 at 7:13 AM, William Allen Simpson

Re: [Nfs-ganesha-devel] 'missed' recv with 2.6-rc2?

Hi Bill, Are you planning to pull this into the next ganesha RC? Thanks, Pradeep On Sun, Jan 28, 2018 at 7:13 AM, William Allen Simpson < william.allen.simp...@gmail.com> wrote: > On 1/27/18 4:07 PM, Pradeep wrote: > >> ​Here is what I see in the log (the '2' is what I added to figure out >>

Re: [Nfs-ganesha-devel] 'missed' recv with 2.6-rc2?

On 1/27/18 4:07 PM, Pradeep wrote: ​Here is what I see in the log (the '2' is what I added to figure out which recv failed): nfs-ganesha-199008[svc_948] rpc :TIRPC :WARN :svc_vc_recv: 0x7f91c0861400 fd 21 recv errno 11 (try again) 2 176​ The fix looks good. Thanks Bill. Thanks for the

Re: [Nfs-ganesha-devel] 'missed' recv with 2.6-rc2?

On Sat, Jan 27, 2018 at 7:00 AM, William Allen Simpson < william.allen.simp...@gmail.com> wrote: > On 1/27/18 9:56 AM, William Allen Simpson wrote: > >> I'm not able to reproduce. Could you tell me which EAGAIN is >> happening? The log line will say "svc_vc_wait" or "svc_vc_recv", >> and have

Re: [Nfs-ganesha-devel] 'missed' recv with 2.6-rc2?

On 1/27/18 9:56 AM, William Allen Simpson wrote: I'm not able to reproduce.  Could you tell me which EAGAIN is happening?  The log line will say "svc_vc_wait" or "svc_vc_recv", and have the actual error code on it.  Maybe this is EWOULDBLOCK? Of course, neither EAGAIN or EWOULDBLOCK should be

Re: [Nfs-ganesha-devel] 'missed' recv with 2.6-rc2?

On 1/26/18 8:53 PM, William Allen Simpson wrote: In fact, I don't understand how we could get EAGAIN, according to the documentation.  But it's logged.  Good idea about differentiating the two identical log lines.  I'd prefer text rather than the number 2. And in the adjacent code, you'll see

Re: [Nfs-ganesha-devel] 'missed' recv with 2.6-rc2?

On 1/26/18 12:18 PM, Pradeep wrote: In svc_vc_recv(), we handle the case of incomplete receive by rearming the FD and returning ( if xd->sx_fbtbc is not zero). In the case of EAGAIN also shouldn't we be doing the same? epoll is ONESHOT; so new receives won't give new events until epoll_ctl() is

Re: [Nfs-ganesha-devel] 'missed' recv with 2.6-rc2?

Hi Dan, In svc_vc_recv(), we handle the case of incomplete receive by rearming the FD and returning ( if xd->sx_fbtbc is not zero). In the case of EAGAIN also shouldn't we be doing the same? epoll is ONESHOT; so new receives won't give new events until epoll_ctl() is called, right? I tried

Re: [Nfs-ganesha-devel] 'missed' recv with 2.6-rc2?

Yes, I wasn't claiming there is anything missing. Before 2.6, there was a rearm method being called. Matt On Fri, Jan 26, 2018 at 9:20 AM, Daniel Gryniewicz wrote: > I don't think you re-arm a FD in epoll. You arm it once, and it fires until > you disarm it, as far as I know.

Re: [Nfs-ganesha-devel] 'missed' recv with 2.6-rc2?

I don't think you re-arm a FD in epoll. You arm it once, and it fires until you disarm it, as far as I know. You just call epoll_wait() to get new events. The thread model is a bit odd; When the epoll fires, all the events are found, and a thread is submitted for each one except one. That

Re: [Nfs-ganesha-devel] 'missed' recv with 2.6-rc2?

Hmm. We used to handle that ;) Matt On Thu, Jan 25, 2018 at 9:11 PM, Pradeep wrote: > If recv() returns EAGAIN, then svc_vc_recv() returns without rearming the > epoll_fd. How does it get back to svc_vc_recv() again? > > On Wed, Jan 24, 2018 at 9:26 PM, Pradeep

Re: [Nfs-ganesha-devel] 'missed' recv with 2.6-rc2?

If recv() returns EAGAIN, then svc_vc_recv() returns without rearming the epoll_fd. How does it get back to svc_vc_recv() again? On Wed, Jan 24, 2018 at 9:26 PM, Pradeep wrote: > Hello, > > I seem to be hitting a corner case where ganesha (2.6-rc2) does not > respond to

[Nfs-ganesha-devel] 'missed' recv with 2.6-rc2?

Hello, I seem to be hitting a corner case where ganesha (2.6-rc2) does not respond to a RENEW request from 4.0 client. Enabled the debug logs and noticed that NFS layer has not seen the RENEW request (I can see it in tcpdump). I collected netstat output periodically and found that there is a