For now, this provides common abstraction for Linux epoll
and FreeBSD kqueue. It also provides the basis for future
changes where alternate userspace TCP stacks have their own
mechanism for polling a group of descriptors.
While here, remove old epoll/kqueue code in iscsi/conn.c that
was commented out when the iSCSI idle connection code was
recently removed - we now have a real implementation of it
in sock.c so the original code is no longer needed as a
reference.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I664ae32a5ff4d37711b7f534149eb0eb35942335
Reviewed-on: https://review.gerrithub.io/398969
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
This provides an abstraction layer around TCP
sockets. Previously we just used fd integers, but
we don't want to be tied to integers for alternative
userspace TCP stacks.
Future patches will do more work to enable multiple
implementations of this abstraction. For now, just
get the abstraction in place for POSIX sockets and
make all of the iSCSI changes associated with it.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I9a825e9e02eb6927c8702d205665c626f57b3771
Reviewed-on: https://review.gerrithub.io/398861
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Ziye Yang <optimistyzy@gmail.com>
The socket-related code was already broken out into
lib/net/sock.c, so break out the header portions
from include/spdk/net.h into its own sock.h.
This prepares for some upcoming changes in how
TCP sockets are abstracted, to enable alternative
userspace TCP stack implementations to be used with
SPDK.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I40b162e72ea80c235b49f10b17c2085fcfb385d4
Reviewed-on: https://review.gerrithub.io/398851
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Ziye Yang <optimistyzy@gmail.com>
Reviewed-by: <shuhei.matsumoto.xt@hitachi.com>
